As October ended with the , I and other attendees with inconveniently long memories were comparing our recollections of promises past.
Stop me if youve heard this one before, but I have a specific scenario that I use to illustrate just what we might someday hope to get from a genuinely object-oriented data store. Suppose we have an enterprise whose operations are divided and reported in terms of eastern and western regions. Suppose we deploy internal applications that either compare or consolidate the numbers reported by these two regions. To the user, the underlying data structures are irrelevant—as they should be.
Suppose growth in the western region makes it desirable, for any number of reasons, to split that region into northwest and southwest regions. How must our users and our in-house application developers cope with this change? Dumb applications, written to use dumb file systems, have to consider two groups of users. The group whose interest is based on geography will want to consolidate the two new western regions into one composite set of numbers; the group whose interest is based on the organization chart will want its reports recast in terms of three regions rather than two.
Our developers will have to search all of our applications for references to the old western region and decide whether each reference should be updated by combining or by enumerating the two new regions. Applications that dont get fixed will die when they try to open a file that no longer exists or will return wrong results if they misuse one of the two “western” files as if it still covered half of the country.
Smarter applications might have been written to use a database instead of discrete data files. Applications written for “organizational” users will ask the database what regions are defined and report accordingly. Metadata approaches, like Longhorns, might take this approach. Applications written for “geographical” users will query “western” tables that no longer physically exist, but that we can define as virtual tables and rebuild as needed: Microsofts promised Yukon database technology can support this direction.
So we dont need an object-oriented file system: We just need relational database servers. Right? Wrong. Were still talking about static, quickly outdated data. What about applications that dont need the most recent definite number but the best possible current estimate? Such applications might use the current database value if its new, or invoke some kind of forecasting algorithm if the “hard” numbers are seriously out of date.
Such needs are best met by information architectures that hide the difference between (i) a physical table, (ii) an operation performed on physical tables, or (iii) an object that encapsulates high-end knowledge for applications convenient use.
For years, Microsoft told us that the essence of its long-promised Cairo was a new foundation of this kind. Without that foundation, were just redecorating the same old rickety shack. Users wont be fooled forever by such superficial change.
And if youve read this far, congratulations: youve gotten to the punch line. The preceding eight paragraphs, beginning with “Suppose we have an enterprise whose operations are divided,” are taken (with only a few updated references and trivial edits) from a column that I wrote on June 3, 1996. Yes, we have been talking about this need—and this promise—for that long.
At that time, Microsoft had just announced that it would scale back the object-oriented Cairo initiative from what had previously been promised, in what was then called Windows NT 5.0. So, am I happy to see that Longhorn, with WinFS, aspires to what one might call a Windows NT 4.8 level of intelligent storage? And only eight years later than Cairo was, in all seriousness, promised in the first place? I suspect that this question answers itself.
Make no mistake, I was genuinely impressed by much of what I saw at PDC, as Ill discuss further in my eWEEK column a week from today. The PDC keynotes demonstrated almost telepathic speed, and intuitive ease, of organizing static data by any of several criteria on the fly. These were real, live demos using real, live bits. You have to respect people who can write that kind of code and who have the guts to get up there and show it to several thousand highly perceptive observers.
But note that I said, “static data.”
If Longhorn and WinFS make it easier to look at what we already know, my concern is that well do that—instead of developing a more advanced model of data that gives us equal ease of access to that which was, that which is, and that which may soon be.