July 2007 - Posts
The topic of the post might not make sense, initially. If I invoke a method asynchronously, why would I want to wait for a return value? And if I'm waiting, what's the point of launching it asynchronously?
Well, the most common scenario is when I want to run a process that could take time and might freeze on me, but I want to limit the time it can take and throw an exception if the timeout is exceeded. This means running the main logic in a worker thread, which means we have to find a way to get the result back to the calling method.
A simple pattern for this can take advantage of C#'s anonymous delegates to pass the return value directly into a local variable in the calling method. This means we don't have to rely on a class member to pass the info, which would need more work in a multithreaded scenario. The end result is very simple:
public MyObject GetData(TimeSpan timeout)
{
MyObject returnedData;
Thread t = new Thread(
delegate()
{
// Return value directly to local variable.
returnedData = BigComponent.DoHeavyProcessing();
});
t.Start();
bool success = t.Join(timeout); // Wait for the thread until the timeout expires.
if (success)
return returnedData;
else
throw new TimeoutException();
}
Behind the scenes, the compiler will build a new anonymous type for my delegate method, and will add code to synchronize the new object I create inside the anonymous delegate into the local variable in GetData(). Simple and elegant.
I downloaded the new Sharepoint 2007 SDK today, published last week though it's dated from April 2007. There appears to be no change history for this version of the SDK.
I was hoping for more information on new Web Service methods available in 2007 - hoping that the lack of 2007-specific functionality was more of a documentation error than an actual oversight. It seems this is not the case.
I've written about the lack of item-level permissions in the WSSv3 web services before, but I've found some other serious problems.
Documentation-wise, the new ChangeLog methods (GetChanges() in various web services) remain almost entirely undocumented.
The Permissions web service, like the previous problem, seems entirely unmigrated to WSSv3 and remains identical to the WSSv2 version. The painful point for me right now is that AddPermissions accepts a 32bit integer for the PermissionMask parameter matching a value in the 32bit SPRights enum - even though WSSv3 marks that enum as Obsolete, replacing it with the 64bit SPBasePermissions enum. This means I cannot set permissions to any of the extended values via web services, only via the object model.
In short, I am quite disappointed with WSSv3's web service support, and even more with the documentation. I get more information from the WSDL at http://myServer/_vti_bin/sitedata.asmx?op=GetChanges than I do from the documentation, and that's a shame.
How did I miss this until now? It's great that WSSv3 and MOSS give us granular permissions, and it's great that I can access those permissions via an SPListItem's RoleAssignments collection - but is there really no way of getting this information in a web service?
The Permissions web service remains unchanged from WSSv2, GetPermissionCollection() receiving a List GUID and returning permissions for that list. Nothing for specific documents. Interestingly enough, the method also receives an objectType string, which could ostensibly allow us to pass other types of objects and get permissions data for them - but this apparently never made the cut for WSSv3 RTM.
This, for me, is a major roadblock. I am limited to accessing the built-in web-services only. I don't have access to the Sharepoint server(s), and can't write my own web-services to expose this data via the object model.
Has anyone ran into this and found a more imaginative workaround for this really painful oversight?
More Posts