Mike Fitzmaurice started his blog a while ago and after a period of silence he's giving his opinion again in blogsphere. In a few of his latest posts, he's talking about things that will be in the next version of Sharepoint. A brief overview:
Webparts:
- WSS “v3” (and anything built on top of it like SPS) is being written with ASP.NET 2.0, and will use, natively, ASP.NET 2.0 Web Parts.
- WSS “v3” (and anything built on top of it like SPS) will carry forward the object models used for SharePoint Web Parts, so it will continue to run anything being written today. Natively. Anything you write today will still work tomorrow.
- ASP.NET 2.0–only sites that do not involve SharePoint technology will only run ASP.NET 2.0 Web Parts.
Some more info on .Net 2.0 with Sharepoint 2003:
- WSS “v2” (the currently-shipping version) won’t magically acquire the ability to host ASP.NET 2.0 Web Parts when WSS Service Pack 2 ships. WSS Service Pack 2’s date and fix list aren’t publicly sharable yet, with one exception: WSS SP2 will allow WSS and the ASP.NET 2.0 runtime to coexist on the same machine. And in case you didn’t connect the dots… Attention: Until WSS Service Pack 2 ships, do NOT attempt to install Visual Studio 2005 or the ASP.NET 2.0 runtime on a machine running WSS or SPS. Until WSS SP2 is installed, doing so will break WSS/SPS.
- The WSS and ASP.NET teams are exploring ways to encapsulate and host some of the functionality of ASP.NET 2.0 Web Parts in WSS “v2”. We’re not guaranteeing that it will happen at all, let alone how and when it would happen. If it happens, you should treat it like a happy surprise — don’t make plans that depend on it. If it happens, you’ll hear about it here (and other places, too, of course).
http://blogs.msdn.com/mikefitz/archive/2005/03/17/397775.aspx
Frontpage RPC's:
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.
http://blogs.msdn.com/mikefitz/archive/2005/03/14/395112.aspx
CAML:
CAML is here to stay. CAML is just too useful to kill. It covers both data and rendering instructions. It lets our List Viewer Web Part fetch a list and its rendering instructions in one step and then only have to apply the rendering to the data. It's blazingly fast. It's also backward compatible with everything we've done to date.
http://blogs.msdn.com/mikefitz/archive/2005/03/13/394974.aspx