Slashdot Mirror
WinFS' Spot on Back Burner Nothing New
osViews.com writes "Charles Arthur of Independant.co.uk has an interesting editorial which analyzes Microsoft's recently postponed 'WinFS,' the file system that Microsoft had been planning to implement in Longhorn. His editorial reminds us that this technology, previously referred to as the 'NT Object Filing System' was intended for a previous version of one of Microsoft's operating system's code named 'Cairo.' Microsoft first spoke of the 'NT Object Filing System' in 1992 and scheduled a beta release in 1996 and then a full release in 1997. But limitations cause it to continue being delayed."
...is a solution in search of a problem?
Or for that matter the ORIGINAL goal of the Gnu project?
What's your point here? Why are you trying to bash Microsoft just because they decided to delay or abandon something?
Best Buy can have you arrested
To how many of Mircrosoft's MILLIONS of consumers, is a filesystem like 'WinFS' (theoretically) a feature to be desired?
Most people I know want eye candy, and things to work as they're used too.
Microsoft doesn't _need_ WinFS, therefore it's not a prime concern
Error 407 - No creative sig found
People COULD just use naming conventions and name their files according to the content. But I guess that's just too hard.
Microsoft "solved" this problem for all intents and purposes by having every program save its files in the "My Documents" folder or a subfolder therein, and allowing for filenames that can be long and have spaces.
Sometimes I feel like Microsoft is rearranging the deck chairs while the ship is sinking. Anyone remember that cool "Tripping the Rift" movie? The ship is falling to pieces and the onboard repair robot repaired the machine that makes ice cubes first. The outraged captain smacked it with wrench and screamed "We're floating in space you decide to fix the stupid ice machine? Get to work on the fucking hyperdrive!!!"
Microsoft need a similar push.
Good point. Looking at their documentation, what they are trying is indeed isn't that simple. You raise a lot of the issues they deal with in adding extensible metadata and relationships while keeping backward compability with existing NTFS file system (Journaled b-tree).
Okay, take that and add a pretty comprehensive default set of metadata. The WinFS base schema is not small, and it covers a lot of stuff.
The next thing is that storing the data is one thing. The other part is storing functionality with the metadata, and allowing third-parties to do the same, and then providing a standard way to access that functionality.
One example is address data. Not that WinFS does this out of the box, but the idea is that if you had a mapping application or service, you could make an addin that would allow somebody to build a search or query like "Find all word documents that refer to people with addresses within 2 miles of this address"
The next part is that there is a whole set of APIs that allow for rule based management that allows developers (and maybe even users) a standard way of building complex actions when events in files occur.
By the way, the Semantic Web stuff is aimed at this kind of functionality as well. Of course, on the web, it's just nuts, but it doesn't mean that the effort can't have value.
Hate them or not, I do like that MS sometimes keeps trying to make something happen, rather than worrying if can be done. They may never get there, but from what I've seen of WinFS documentation, there is real power there.
Spotlight is close, but from what I can tell, the metadata is managed apart from the files, and the set of gathered metadata is by default smaller.
In think, a lot of what Spotlight can do the MS Search service can do already via indexing, but the interface leaves a ton to be desired (There are APIs for making search/index extensions. See the Adobe IFilter plug-in for example).
Where Spotlight really works well is the UI. That's important, and MS is lagging there, but I think they can catch up some.
And that the challenge for MS as well, is getting the technology to the point that it doesn't require lots of tech knowledge to use the stuff well.
There's a system that exists already and that's not vaporware. ReiserFS 4.
You can "cd" into a file like a directory and see the metadata. Things like bitrate for MP3, and all that stuff.
SQL doesn't fit that well with filesystems, btw. Relational databases work great with rigid categories. But beyond very rudimentary classification it won't work well because everybody has their own idea of what a good classification should look like.
Glomming two related services into one blob of unmaintainable code is not necessarily a benefit. A database mapping has the advantage of being able to catalog distributed file systems, including those which don't have any object tag extensions.
The other problem is that it's not uncommon in the database world to spend far more disk indexing complex data for access than it actually takes to store the raw information itself. Do you really want the possibility that your inseperable all-in-one file system is using more space for the equivalent of directory entries than for data itself?
Remember this isn't about special cases like a user too lazy to sort their home directory or documents folder, but applying that overhead to the entire system. With all the tweaks people do to improve general FS performance and reliability, why would anyone think adding overhead is a good idea unless you need, and I mean need those features?
If you do indeed need those features so badly, why not just buy or use one of dozens of existing document storage and search facilities?
WinFS was just trying to find a way to make people think the two ideas were inextricably bound together and in some way unique to Windows. In truth that honour goes to hundreds of document database and repository products and the long-toothed AS400 (or so my cohorts tell me that work on the platform.)
I do not fail; I succeed at finding out what does not work.
Right now, Reiser hasn't even conviced Linus and Viro to include Reiser4 into the stock kernel. Much less convince KDE/Gnome/Mozila/OpenOffice/etc/etc/etc to adapt their stuff to his interfaces. So, no, I don't think he's in the same position as Microsoft (who can coordinate this across the OS, the shell, and in many applicaitons at once) at all.
Business. Numbers. Money. People. Computer World.
As far as i can see, there are two different concepts in that thing:
- The real FS part: ReiserFS-like storing of a file/dir architecture, which is nice, disk-space-savey and all, but has no consequences on the way people work. Furthermore it already exists: i'm using it right now.
- The self-organized document hierarchy and search capabilities, which might change the way people work for the best, as far as it's restrained to *very specific parts* of your data. Who would trade a well crafted UNIX dirs architecture for a key indexed FS? What about dirs related documents, like a hierarchy of Java packages? What about URL accessible documents? What about implicit (not already keyword-based) relations between documents? And so on... In most cases, this stuff would have to emulate a standard file hierarchy anyway, which would probably result in system resource overhead only, or would require that you specify explicit keywords (not really knowing how they would impact the search algorythm), which would result in user resource overhead only.
You get my point: this stuff must be an option, and it belongs to the user interface, as in DBFS or Google, with a standard lib/API for easy re-usability by tiers software. It would be of no use with MOST of the files, in my system anyway.
WinFS is not even a solution looking for a problem, it's a problem seeking naive clients for its solution, IMHO.
"Take away our PlayStations
And we're a third-world nation"
A.D.