Longhorn: The nuts and bolts
Published: 04 Nov 2003 15:55 GMT
Enter the notion of schema-based data objects. A programmer defines a schema for the data he or she is going to store which details what kind of properties and operations it will support. He or she then registers this schema with the system, which enables the creation of objects of that type in WinFS. Schemas for audio files, word processing documents, and others will ship as a standard part of the Longhorn WinFS system, which programmers can reuse in their own applications.
Any kind of value can be associated with a schema object, including objects which adhere to another schema, leading to object relationships. For instance, a custom object type of "PDCAttendee" can be created and registered with the system, enabling a list of PDCAttendee objects to be created on disk. This list can be retrieved and displayed, and those individual PDCAttendees can be associated with other schema-based objects on the system, enabling searches that retrieve objects based on their association with a particular PDC Attendee.
This search capability is important given the replacement of the notion of a "folder" into which data is categorised with the WinFS concept of "views". Views are displays of data retrieved from the WinFS file system based on the result of a particular search. Data relationships can be used in searches, which are composed using a new, object-based, SQL-style search language for accessing these objects (users likely won't see this language, but developers certainly will). These views are updated as the data underlying the elements gets updated. Standards sets of views exist on the system, but the ability exists for custom views based on custom searches to be created by end users.
One of the advantages of the WinFS approach to data management is that data formats are completely transparent. A schema defines the characteristics of the data, making it available to anything on the system that wants to talk to it. If other email client providers such as Eudora decide to adhere to the "Mail" standard schema, that data will be accessible from Outlook Express, and vice versa.
In short, WinFS replaces the notion of opaque data blobs that contain an unknown "something" with a richer model wherein data conforms to a particular schema type, enabling easier location and more transparency in data formats.
The Longhorn Communications Stack: Indigo
The PDC broke the essential advances of the Longhorn OS into UI (Avalon), Data (WinFS), and Communications (Indigo) in reflection of the importance that each represents to Longhorn. Indigo's centrality of place shows the importance Microsoft ascribes to network communications.
Indigo, however, does not involve as great a leap philosophically as Avalon and WinFS. Microsoft's Indigo communications stack will include libraries for building peer-to-peer networks and constructing secure and encrypted Web services on both server AND client systems, among other things. Such technology is already common, both upon Windows and other platforms.
Indigo, however, is a refactoring of Windows communication technology as it currently exists, designed to create a system that is less fragmented, more extensible and more standardised from an API standpoint. This is in keeping with the greater flexibility and consistency already present in technologies such as .Net Remoting or in ASP.Net's Web services architecture.
Indigo also represents a move away from the notion of remotable objects. In a presentation of the design philosophy followed by the Indigo development team (PDC attendees might remember it as the one where Mr. Box wrapped his legs around a hapless volunteer from the audience), Don Box declared that Web services are a better manner in which to exchange information between machines than remotable objects. Forcing programmers to think of inter-machine communications as truly a call to a SEPARATE machine (and not just to a local object in your namespace that looks, for all intents and purposes, like a local object) prevents bad inter-machine communication design decisions.
For that reason, Indigo will operate along the Web service model seen in ASP.Net .asmx files (which are ASP.Net's Web service definition files), and not the object remoting model seen in DCOM, CORBA or even .Net Remoting.
Why is Longhorn code being released so early?
There are a number of features I don't have time to deal with here, such as Microsoft's new XML-based build tool (msbuild) that will be common across all their SDKs and integrated into Longhorn, the new NGSCB / DRM functionality that will make Longhorn a more secure platform and open up new revenue-generation possibilities for small ISVs, the new controls that will ship with Longhorn, and a host of details relating to Avalon, WinFS and Indigo.
Likewise, there are a number of questions I have yet to answer, such as how they are going to handle interoperability between other systems (Pocket PC devices, or older versions of Windows) and WinFS, or how WinFS objects can be copied to another machine (remember, those schema objects have linkages to other pieces of data on the source system).
This explains, however, why Microsoft chose to release Longhorn so early. The large feature set and the new approaches to application development offered by Longhorn will take some time to digest. Every PDC attendee walked away with a working copy of Longhorn, even if pre-alpha, allowing them to start writing experimental applications today (and, I might add, negating claims of the vapourware status of Longhorn). This allows information about Longhorn to flow out of Microsoft into the developers that will write products for it, as well as allow developers to influence the final features that will exist in the released product.
Longhorn at this point is not a product that is set in stone. Developers can influence the final shape of Longhorn, a fact hammered home multiple times over the course of the PDC. This, to my mind, is the number one reason to release code so early. Open-source programmers have access to the latest build of Linux. Programmers of proprietary operating systems have access to early release versions of next generation operating systems. The two are flip sides of the same coin. Which you prefer depends on your programming philosophy.
Parting Thoughts
In closing, I offer a warning to fans of other operating systems. If history is any guide, much effort will be expended trying to downplay the importance of Longhorn, if not suggest that no one will, in fact, buy the product. Besides the fact that history seems to counter such naysayers (.Net is popular, as is PocketPC, XBox, SQL Server, Windows XP and the various components of Office), it provides a rationale for a lot of people to do nothing to respond.
Consumers don't tend to be privy to the ideological warfare that shapes so much of the dialogue between programmers in the various programming domains, and are thus unlikely to be swayed by such arguments. Mark my words, Longhorn will be immensely popular once it is released, because Longhorn is revolutionary technology that makes desktop computing better.
Proper competition demands that you reject the comforting fantasy that Microsoft never does anything right, and deal with the reality of what their technology offers consumers. So, as a final point (in the "sharp stick in the backside" sense), it's time to start learning from Longhorn so as to plan an adequate response to it.
John Carroll is a software engineer now living in Geneva, Switzerland. He specialises in the design and development of distributed systems using Java and .Net. He is also the founder of Turtleneck Software.
Previous
Did you find this article useful?
46 out of 85 people found this useful
Digg
Slashdot
Del.ici.ous
Stumble
Reddit
