If you’ve been at a talk delivered by me, Bryan Jeffries, or Richard Mareno entitled something like “Programming with Windows SharePoint Services’ Lists and Document Libraries”, you’ll have heard the following explanation, but in case you haven’t, or if you’d like to see it repeated in print…

If you want to work with documents in SharePoint Document Libraries, and you need to do so remotely, you’d be well-served to get familiar with FrontPage RPCs.  Why?

  • Our object model isn’t remotable.  If you’re doing work on the server, this isn’t a problem.  But if you’re doing server-to-server work or smart client work, this matters a lot.
  • SOAP can’t chunk; specifically, it doesn’t have a means to break up an envelope into multiple transmissions, send them across, and reassemble them on the other side.  Do you want to send a 50mb file over the wire in what amounts to a 75mb all-or-nothing post?  I didn’t think so.  SOAP is fine for enumerating and accessing everything about a document but its contents, but you’ll need to supplement it with something else to do the actual I/O.
  • WebDAV does chunk.  But it doesn’t know how to version (which is funny, since DAV stands for Distributed Authoring and Versioning).  It also doesn’t know how to do a checkin or checkout.  Batch operations?  Forget it.

    Now you could opt for a SOAP/WebDAV combination.  Do the actual PUT/GET via WebDAV, and use SOAP for everything else.  LISTS.ASMX can handle metadata already.  The checkin/checkout you’d have to do by addiing a new Web service of your own (see Writing Custom Web Services for SharePoint Products and Technologies for details).  But you’d still have trouble getting at old versions of documents.  And if someone turned on automatic versioning, you’d run the risk of generating an extra version when you set custom metadata.  Moreover, if someone wanted to make some SOAP metadata changes to a document for which a WebDAV lock was in effect, the SOAP calls would fail.

Ultimately there’s only one technique that lets you get/set metadata, perform checkouts/checkins, read/write documents, and easily get at their various versions — FrontPage RPCs.  It’s an umbrella term for a set of techniques we’d kill if we could, but (1) they support everything we and you would need, and (2) they’re backward-compatible.  What are FrontPage RPCs?

  • When we say FrontPage RPCs in general, we’re really talking about both the FrontPage Remote Procedure Call methods (which have nothing to do with the DCE RPCs that normally come to mind when we hear “RPC”) implemented by both the FrontPage Server Extensions and by Windows SharePoint Services, as well as the Windows SharePoint Services RPC methods implemented only by WSS.
  • They’re structured commands either passed directly to OWSSVR.DLL as query string parameters (a.k.a. the URL Protocol) or sent to OWSSVR.DLL as a set of batched commands formatted as CAML XML.
  • They’re what Office client applications use to handle document I/O and checkins/checkouts of documents in SharePoint libraries.  (SOAP is, however, what’s used in the Shared Workspace task pane.)
  • They’re documented at http://msdn.microsoft.com/library/en-us/spptsdk/html/SPPTWSSClientAPI_SV01072206.asp, although that documentation is pretty much all references without examples or “how-to” tips.

Given that FPRPCs are here to stay for some time, we’ll do something about documenting them better over the next several weeks and months.  I’m going to get a number of examples posted to GotDotNet.  I’m also checking with a few people to see if someone’s willing to write a .NET helper class that handles the most common uses of FPRPCs; you could just insert this in your projects and have an easier time of working with SharePoint library content.

In the meantime, though, you can and should look into the subject on MSDN.  Also check out a Webcast that covers this subject in part:  Programming SharePoint Site Lists and Document Libraries.  And stay tuned for more.