My 4 continents in 4 months drinking buddy Stephen Forte thinks I am insane (that from him!) for keeping all blog stuff in XML files instead of SQL and I just had a quick chat with Jason Whittington about multi-user capabilities for dasBlog.

So... here's a couple of points on what I am thinking about "storage futures" for dasBlog.

XML files are goodness for small sites. There are a lot of folks I met who don't have SQL Server acess for their sites or don't want to deal with the additional complexity. I reckon that it's still a minor administrative burden to set up the permissions, but that's much less than administering your SQL store. Still, SQL is of course superior of sites that have more traffic, because it excels in dealing with concurrency, data consistency and all the database goodness. Come Yukon, there's a great way to mix the extensibility of XML and the power of SQL in a very rich way (to use a Microsoft marketing phrase). And of course, for folks like Stephen, SQL administration is something they do in their sleep. For SQL 2000, I am thinking about submitting Infoset to the data service, breaking out the elements needed for relations and indexes and store everything else as a BLOB. dasBlog only looks at the entry id, the date and the categories when looking for entries so that seems sufficient.

WinFS seems a great way to store the files and add search. I will have to look into that, but it's too far out to even do a prototype.

Multi-User capability is what I discussed with Jason. He suggested that the "author" is just another field. I disagree. The multi-user version of dasBlog (there will be one) will be organized in a very different way. I will actually keep the content absolutely separate on a per-user basis. Site config will be split into user preferences and site preferences. There will be master themes and user-supplied themes. However, there won't be a merged store. Reason: If I am blogging at a shared site and I want to move to a site that I host myself, I want to be able to take the content and make the move myself. Xcopy. If your weblog is on a site with a common store, you will have to extract and remove your content first and that may hard to do and may break stuff in the end, because there may be dependencies in the store that you don't know about. What I am going to do with the multiuser model is that there will be one runtime and app, but content, templates and content will be stored in subdirectories. If you want to move away from a shared site, you grab your stuff drop it into a single-user blog and it just works.

On the inside, the multi-user version will keep one data service instance (and cache) for each user and the portal page will by fed by a data service that aggregates all user data services and creates combined results. Logging will be separate for each user, but the logging information will be fanned out to the common site-wide logging service as well.