Exclusive Sources close to Microsoft confirm that The Beast is set to include a new relational file store at the core of its next version of Windows. Some roadmap slippage has apparently occurred, too, as the database core will be introduced into Longhorn, and Blackcomb has been pushed further back. That leaves a gap for a point revision of XP next year, although there's no sign of this on the roadmap just yet. Despite the annual revisions being named as users' number one bugbear, Microsoft hasn't let a year go by without releasing a new version of Windows since 1997, when it was fighting the browser wars.
The final feature set for Longhorn - the codename for the successor to Windows XP - hasn't been nailed down yet, and the database core had been rumored for inclusion in Blackcomb, the next Windows after Longhorn.
It's highly significant, as it signals a much tighter integration between Microsoft's enterprise server products and the client.
As Jon Honeyball wrote here last May - but it's still the most comprehensive dissection of the change - file systems would become plug-ins for a raw, native relational data store.
We don't yet know if this runs in user land, or kernel mode.
Peep to Peep
Microsoft will also offer a new peer-to-peer networking feature, say sources briefed by The Beast. A new "sub-workgroup" network level - a subset of the current "workgroup" - offers a finer granularity of network access for ad hoc collaboration. Microsoft is intent on P2P-style workgroup collaboration looks seamless, with additional updates to NetMeeting built in to the OS.
The demonstration version of Longhorn currently being demoed to Microsoft's teams and selected third parties displays a new type of task dock that can include everything from stock tickers to work group collaboration features. The task dock is similar to what is found in Office XP with the tasks panels. That's the pane in Office XP that provides a list of most recently used files, or clipboard entries, or other frequently-accessed features.
Sources tell us that the Longhorn "screenshots" showing some of this functionality currently doing the rounds, but sources briefed by Microsoft assure us these are not genuine.
Sane, useful, legal?
There's a sensible rationale for such a move, argue advocates: our data stores are confined to silos such as our email application. A shared namespace would allow distributed corporate queries such as 'Find emails from Bob to Carole about ProjectX in FacilityY'.
Although Microsoft has touted such a vision for a decade, precedents are rare. They've run into performance issues, and no namespace schema has won general acceptance.
Hans Reiser, of ReiserFS fame, has been leading the discussion in how free software can respond to the challenge, and his arguments are summarized in his excellent paper here which should be compulsory reading.
As we noted last year, Pick and IBM's OS/400 effectively run a data store as the file system, but they didn't get there from here, so to speak, having designed the OS around such an architecture from the ground up. On the desktop, the late Be Inc attempted such an ambitious scheme (hi Benoit) before reverting to a more conventional file system layer which has database-like properties [see Bootnote below].
The move has antitrust implications: it potentially puts Microsoft at an advantage over Oracle and other competing SQL implementations every copy of Windows will effectively come with a light version of Microsoft SQL Server.
In practice, however, a distributed database is only as strong as its weakest link, and we can't imagine a corporate IS manager who'd turf out Oracle for a distributed network of Windows PCs running Longhorn. A mantra in recent years has been that IBM and Sun offer a "single point of failure", but the dangers of multiple points of failure become more stark in a distributed system. Want last quarter's accounts receivable? Ah, you'll have to wait until the cleaner's unplugged the Hoover. ®
Bootnote: Dominic Giampaulo, designer of the Be file system BFS, mailed us with this clarification:-
"The first system, written by Benoit Shillings, was actually generic hierarchical file system with a database built on top (in user space) and maintained on the side. I wrote the successor to that, BFS, which was a more tightly integrated system. The attributes could be indexed and the indexing was done on the fly -- as you changed
attributes it updated the indices (and would send notifications if any outstanding queries were affected by the change). The indices were
not constantly re-indexed (which implies some sort of disconnected operation). Benoit's system as a whole was more database like than what I did but both could achieve pretty much the same end result for the user. Thanks Dominic.