There’s been much discussion over the past few months about the marriage of databases and filesystems – with Microsoft’s Longhorn reportedly sporting the
Yukon integrated SQL Server, and GNOME Storage in heaty debate, if not development, there’s been lots to talk about.But it’s worth bearing in mind that “Database Filesystems” are not a new idea – in fact, they’ve been in widespread use for many years. For a prime
example, one need look no further than to IBM – their OS/400 operating system, which runs on the iSeries (previously known as the AS/400) minicomputers, features what can best be described as a “DB2 filesystem”.
To those used to DOS or UNIX, the OS/400 filesystem is a little strange. Instead of directories, there are libraries – and libraries cannot contain other libraries – and within those libraries are files. Unlike files in the UNIX world, files under OS/400 are heavily structured.
An OS/400 file can contain any number of members – each having an identical structure. Traditionally, you would group related members of the same type
into a single file; for example, the C source files for a program might be grouped together into a single file. In fact, you can think of an OS/400 file as a collection of database tables all sharing the same definition – because for many purposes they are exactly that.
That might sound strange – and you might well wonder how C source code can be stored in rows and columns – wouldn’t that be horribly complicated? In reality,
it’s very simple; C source code on the iSeries has three ‘fields’ – the line number, the date and time it was last modified, and the text of the line itself – and each ‘row’ is a line of the source code.
This probaby seems like quite an inefficient way of storing C source code – and you could be right – although it makes writing an editor a little easier!
But think about this: if every file has a structure akin to a database table – and can be treated like a database table – and you can still read and write to the members as easily as you can read and write to a file under UNIX or Windows, you have an immensely powerful system.
Under this system, the need for custom file formats vanishes; you just store your data as you would logically store it in a database table. And of course,
getting information out again is no more difficult than performing a query.
If you’re a typical user (if there is such a thing), you might be wondering what the big deal is – and you’d be right to. The implementation of file
storage isn’t something users should normally ever have to worry about – and the big deal is that you probably do have to worry about it from time
to time, and anything that means you have to do that less often is probably a good thing.
If you’re a developer, I’m hoping that you can see the possibilities of such a system. There’s often occasions where using a database for storage would be
really useful – but requiring MySQL or Postgres, or even just an ODBC connection, is just too heavyweight for your utility or application. After all, if Epiphany required a database connection in order to store its preferences, people would soon complain; but if the database was the filesystem, Epiphany could just create a file structured as name and value pairs and use that.
The OS/400 way of doing things is just one implementation – and in a way, the Be Filesystem was another. WinFS and GNOME Storage will add two more, and
nobody really knows quite how they’re going to shape up yet, but if they come anywhere close to the power and flexibility of OS/400’s storage system,
they’ll be worth taking a careful look at.
I’m glad someone said that these have been around for many many years now.. db file storage is NOTHING new, not even close… getting it on windows just seems like a bad idea, microsoft will be controlling what kind of file formats can be defined in the filesystem sounds like bad news to me… of course that isn’t a requirement, but that seems like a logical thing that microsoft will do.
What’s interesting here, not knowing much of anything about the OS/400 platform, is how little of it has drifted into the OSS space.
I’m sure that this system works well on IBM systems because of how tightly integrated it is.
Perhaps the have a thin POSIX layer on top of this system that converts their DB based files into POSIX like streams, because that is probably the key difference between UNIX systems and others. I know the VAX had several structured files that were more than just blobs-o-bytes.
I wonder what the Java API for dealing with their local data is. Write once, run anywhere (on any AS/400, that is..). Never heard if Sun sued IBM over that or not…
The issue of whether to use something like a SQL database for storage has been more an issue with availability than anything else. If there was an integrated DB in the system, with a single instance, then connecting to it would be no more “heavyweight” than “open”, you’d just have a more sophisticated parameter list.
Of course, it would be best if the DB were integrated into the kernel for performance.
One nice assumption that can be made is that a local DB can punt on using SQL, and use something more efficient. SQL is wonderful, but wordy. Dealing with a “pre-parsed”, binary structure would be more efficient for native applications, particularly for simply bulk inserts and bulk reads.
And that’s what a modern rich filesystem will do anyway. They may have a SQL layer for it, but the API will be more akin to something like Berkeley DB (well, hopefully something a little bit richer, a little higher level).
But truly, after all of these years, I keep hearing about Neat Stuff in the AS/400 systems and their architecture, yet have never seen a set of utilities or systems “inspired” by the AS/400 in the wild, at least none that give credit.
Could not be a better idea to implement this kind of functionality in the filesystem, like BeFS and maybe the futur WinFS?
Could an idea if you want more speed no?
P.S. WinFS will use SQLServer no? It’s me or this database was resposible for MANY security hole?
I think we should look at the right light: the fact it’s a db-FS is not the most important thing, MS is not saying they’re revolutionizing on that, the most important is the abstraction layer(s) MS is proposing on top of it, trying to make the system more intuitive for the user.
Not necessarily… a database-backed filesystem could potentially make it more effort to implement proprietry file formats – after all, if you do store data in a strange way, you don’t gain the benefits of database access to the files.
That said, it wouldn’t suprise me in the slightest to see some sort of CRM implemented such that applications can specify what can and can’t access a file using the database APIs.
Assuming that doesn’t happen, for the moment, getting your data out of a file with an unknown format shouldn’t be anymore difficult than extracting data from a database table with an unknown schema. Sure, it’s not the easiest thing in the world, but it’s far easier than decoding seemingly random streams of bytes with no apparent meaning.
It’s worth bearing in mind that SQL is a means, rather than an end. It doesn’t really matter how you can query the data, so long as you can do it easily and effectively. On traditional RDBMses, SQL is the means for doing this – in the future, this may well not be the case.
Of course, there’s nothing stopping someone writing a SQL-savvy front-end to a lower-level database API (after all, that’s pretty much what database servers do now internally).
As far as I know, when you install DB2 itself on an AS/400, all you’re really installing is a SQL-capable front-end to the filesystem (give or take).
The neatest thing about AS/400s is really the fact that they have been very carefully designed for a specific range of tasks, and IBM has been particularly stringent in ensuring compatibility while they improve on that and expand what the systems are capable of.
That said, I tend to hold the view that you can learn something – no matter small – from the design of every system.
I think that’s exactly what Microsoft are doing. When they say “NTFS and SQL server”, I don’t really think they’re just going to put SQL server on top of the existing NTFS and be done with it. We already have the MSDE – which is SQL server in a small package. Perhaps Microsoft are taking that concept further, and integrating the core of that into a kernel-space driver (or even as part of the NTFS core itself).
Also, just because SQL Server, the product, has had many security holes doesn’t mean the database engine is inherently insecure.
At the end of the day, it doesn’t really matter all that much how it’s implemented – so long as it works – and as long as the interface presented to developers is sane and useful.
Never did much work on it (rpg not my thing), but in studying the architecture of the machine, I was impressed, maybe more surprised, that it used db like storage. I guess we’ve come full circle. I’m sure IBM has a number of patents on the thing and it would be interesting if IBM supported bring that type of “filesystem” to Linux. Oh I miss that little space heater
Well, it is a good idea and concept and the MS solution appears to be more polished. MS SQL Server is one of the best databases to date, if they can integrate this or the component into the OS I think it will be great.
At the end of the day, it doesn’t really matter all that much how it’s implemented – so long as it works
>>>>>>>>>>
That’s the same thinking that got you Win 9x, GDI in the kernel, IE deeply integrated with the OS, etc.
and as long as the interface presented to developers is sane and useful.
>>>>>>>>>>>>>
Being insane and useless never seemed to stop anyone from using Win32 and MFC. Windows developers seem to have very low standards for their APIs…
Sorry, I’ll clarify.
It doesn’t matter to the users how it’s implemented.
A user shouldn’t ever have to care.
If WinFS uses a SQL backend, would it then be possible to break into the system by sending emails containing malicious headers, or by visiting webpages that link to files that don’t buffer-overflow IE but the system itself?
On the other hand, I think such a data storage system would be a good idea. One would finally be able to throw away .ini files, all the .conf file formats and GConf/Windows registry.
Longhorn will be a success and MS dominance on the desktop will be reinforced. Adding Sql to the Winfs file system will make this the best operating system to date. One can theorize and make statements of allege flaws, but remember this is still in the development phases and many more revisions will be made to this operating system.
Of course
And Sql server is so stable under heave load
ans so predictable when size of the database is growing …
Having run IBM OS/400 for years, there are a few points I feel I must address.
1. People are confused about a few things. IBM AS/400 / OS/400 was and is still largely today a system built from the ground up, on a single level storage based design. The system does not differentiate between RAM and DISK storage-seeing it rather as a single layer DASD/RAM available to the system.
2. It is only now possible to call it a mini system, it was a replacement for the IBM system/36, and 38, and was more a midrange system. Its whole design was really based around database type applications, and reporting. Its widely used in banks, building societies, life assurance and so forth. Today with logical partitioning its stretching to ISP and internet use, Linux and beyond.
3. Low end performance was and remains nothing to speak of on AS/400. It comes into its own only when you start spending, and only when you supply that single level storage with a lot of disks/actuator arms. We used to run 4 gig drives instead of 8 gig drives and double up on how many we had to drive throughput on the disk systems. In addition, people have totally missed the boat on the whole build of AS/400, as no one has twigged that AS/400 has IO processors beyond its mere CPU subsystems/systems. Then there is microcode on all the hardware and very tight control about access to the operating system. Programs are very ridgid on OS/400 as there are strict adherance to rules when it comes OS/program usage.
There are other aspects to the 400. Backups are a pain timewise with subsystems needing to be closed of and applications closed – a subject that used to drive our business nuts
Uptime is nigh on unbreakable. If you have the correct setup and pay the right money, IBM are onsite before you have a problem. The low level microcode monitoring on hardware is remarkable. The system offers internal diagnostics the PC industry is really still only dreaming off. But all of these things are borne from a system built and planned in a way that I can’t see Longhorn being done in a similar way. The OS/400/AS/400 System was designed this way. Longhorn is just trying to adapt the filesystem to be similar, but OS/400 is not just a filesystem, nor is its single level storage and its internal additional IO processors and subsystems
I think its interesting to think of a database filesystem, but the comparison to OS/400 is a little off base. They are different animals
AdmV
This sort of reminds me of a SouthPark episode where “Captain Chaos” tries to come up with devious plans for world domination and his trusty sidekick keeps pointing out that each plan had already been done on The Simpson’s. Little doubt this was motivated by people suggesting ideas for SouthPark and being told it had already been done on The Simpson’s.
Anyway, Novell did it! Novell Storage Services, available since NetWare 5.0, is an object database with a filesystem abstraction layer on top of it. The current version allows you to split large volumes into smaller ones while retaining the directory structure with something like unix soft links.
AdmV You are so right. I am a windows/linux admin and my boss is the AS400 admin. He supports the legacy version of our ERP software while I deal with the Y2k capable version in PC Server land. It is really impressive what IBM did – albeit at tremendous and monopolistic prices at one time.
To my point, MS owns great plains and ms wants to be more scalable. I don’t know for certain, but the great plains customers will probably look forward to this change because it will be more os400-like. MS can’t survive on software sales alone. They only make money on a couple of products. Everything else is a loss-leader. I suspect that longhorn is an evolution to bring them closer to offering support services. I’ll even bet they’s get Dell involved. Maybe that was a brainless guess..
Lastly, I was wondering if this would mean that ODBC calls to a longhorn server would possibly disappear in a MS network — if you get what I’m asking.
Regarding ‘the simpsons did it’
So, what’s your point? Does Novell’s product get mention in this story? Perhaps I missed that.
What I’ve not seen mentioned is the fact that the operating system exists on top of a virtual machine which includes DB2. The virtual machine was a 256-bit architecture when the System/38 and AS/400 hardware was 48-bit and the rest of the world was 16 and 32-bit. The hardware has changed several times since 1979 but compiled applications rarely need to be re-compiled to run.
The file system is more complicated. There is a root level system which was introduced several years ago which contains the database file system, the document file system, a UNIX-compatible file system, and any user-installed file systems.
As far as applying the database system to work on another operating system, it wouldn’t be easy because it’s not just a file system.
AdmV —
I don’t disagree with anything you’ve said, though I think you might’ve misunderstood what I meant. I didn’t mean to imply that OS/400 is a system built around a database filesystem – more that it’s one of the features of the platform that’s often overlooked, and that it’s not a new idea.
Once you start digging, there’s hundreds, if not thousands, of superb AS/400 features which have barely been touched upon by other systems – I talked about the database-style filesystem because it’s “hot topic” at the moment, rather than anything else.
That said, I’d contend that the terms “minicomputer” (obviously as opposed to “mainframe” or “microcomputer”) and “midrange server” can be used interchangably, but that’s largely academic.
I’ve glanced over the Longhorn docs, but I am curious if anyone knows:
1. How will I backup this kind of store? I can imagine an enterprise will have a backup server that replicates local stores, but what about the home user?
2. How will I restore these kinds of backups? Will I be able to restore this data on my other computers? What if my other computers are running OS X or BSD or Linux?
3. Lots of file formats contain metadata, e.g. a Word document’s author information or an mp3’s id3 tags. If I transfer a file from WinFS to another system, how will that file’s metadata get transfered?
This kind of technology looks like it has some really excitiing applications, but I am concerned that it will make me more dependant on MS to retain and use my data in the future. We shall see.
A long time ago, there was an operating system on IBM big-iron called MTS (Michigan Terminal System) that had a filesystem that was a lot like a simple database with fixed, 4-byte keys, a 2 byte (signed) length, and (1..32767) octets of data.
<p>
Typically, the 4-byte key was treated as a signed integer line number, except that the first line was (decimal) 1000, displayed as “1.000” (with trailing zero blanking.)
<p>
The advantages of this system were numerous. All userids were
1 to 4 characters (uppercase), which mapped directly into that 4-byte key, making various databases based on userid easy. New lines could be inserted into existing files without causing subsequent line numbers to change, making it easier to review printed listings (this was when time on the computer was strictly rationed and printouts were very useful.) There were other advantages too, but I’d rather not drone on too much. Documentation for a program could be put in the “negative” line numbers.
<p>
Of course, there were disadvantages too. Until you renumbered the file (changed the keys), you could find yourself unable to insert a new line between lines 1.123 and lines 1.124. There was no “end-of-line” character. And under this particular implementation, it wasn’t possible to have a zero-length line. (Writing a zero-length line at a particular key was the DELETE operation.) And, of course, the length limit of 32767 was a problem too.
<p>
Basically, there is a problem when you transfer betweeen files that are structured (line these MTS files, OS/400, or the old Macintosh file system) and unstructyred file systems where files are simply a stream of bytes (probably addressable.) And even unstructured filesystems usually have some structure, such as how text is represented, end-of-line conditions, etc.
<p>
Having a structured filesystem can ease certain problems, but it increases the complexity of the system too. And I can’t help but think a filesystem where the schema is configurable (i.e.: user-defined attributes, forks, etc.) then archiving such a mess and inspecting and validating the filesystem after a crash can be a real pain. Of course, if the filesystem is a database, then the OS must take care of issues of simultaneous update in a rigorous way.
Hans Reiser has a *lot* to say about the subject of filesystems and databases. Take a look at http://namesys.com/whitepaper.html for several of his (very verbose) ideas. Look especially for the section at the end titled “Storage Layers Above the FS: A Sure Symptom The FS Developer Has Failed”.
Now, Hans still has to prove he’s right, which is something I think is very evident in his own writings on the Namesys website, but he may be quite right in the end. I’m really excited about Reiser4, and I think a lot of the thought Hans et al. have put into it is often ignored when people on this sight discuss databases and filesystems.
“1. How will I backup this kind of store? I can imagine an enterprise will have a backup server that replicates local stores, but what about the home user?”
There is a synchronisation manager built into the shell. You can select certain files to be kept consistent between various other WinFS systems. This is for colaberative working, document management type scenarios.
Also since the file system is NTFS underneath I expect traditional imaging techniques will work as usual. Backup software vendors will no doubt update their products to fully support longhorn. MS may be working on this themselves, I think backup operations are part of their “PC Satisfaction” product they are currently testing.
“2. How will I restore these kinds of backups? Will I be able to restore this data on my other computers? What if my other computers are running OS X or BSD or Linux?”
Being NTFS, actual files will still be readable under linux with the exisiting NTFS driver. The database meta-data and relationships will not be accessible and some of the files might be hard to find since they may not be stored in hierachical folders and may have filenames generated at random. eg GUIDs
“3. Lots of file formats contain metadata, e.g. a Word document’s author information or an mp3’s id3 tags. If I transfer a file from WinFS to another system, how will that file’s metadata get transfered?”
There will be lots of import filters that will read the existing metadata, (MP3 ID3 Tags, Jpeg EXIF data, Office file metadata) and add it to the WinFS database. When the database stored metadata is updated these changes can be propergated back into the files.
You can create custom filters for reading and writing metadata into your own proprietary file formats. With metadata stored both in the file and the database it is preserved when being transfered between systems.
Geeze and all I have to do now is:
rsync -a . host:~/
And I get a complete backup of all my settings and files on another computer (completely usable also). I think I will stick w/ my own database and query engine thank you… reiserfs and a find tool.
There is nothing wrong with todays folders and files.
Lets keep it simple. You could have a simple DB that keeps
meta data. But lets face it when you move a *.Doc file
to a floppy disk then to another PC the meta data is still
there. Why ?
Because the meta data is in the file and the extra info
about the doc is shown by a plugin, same with the mp3
tags.
If you are onganized you would creat a short cut to
the most important folders. Or even use the find tool
or remember where there are.
We all know that hard drives are getting bigger and
faster. But having a 320GB drive with 300GB meta data
is over the top.
And to the main point all we are still doing is reads
and writes in 512b blocks. It how the software prosents
the information to us. We should be able to turn this
feature off if we dont want to run a mini sql server in
the back ground.
This is all IMHO.
Ready for people to try and prove me wrong
even though these are opinions.
Aaron
They should just adopt the BeFS and pay a bit of money.
It’s not so much about searching for lost files. Its about organisation. With a purely hierachical filesystem you can only arange things in one way.
do you organise things by
artistalbum rackfilename
genreitrateartistfilename
filetypeprojectduedatefilename
contactprojectfilename etc.
What if you want to see all the 4th tracks in one folder?
With the relational database model you can filter by any criteria and view it all as though it was all in one folder.
At the moment you can do this inside apps like iTunes, iPhota, Outlook etc. but this extends the concept to all your documents.
You can relate each file to each other file. See all the files related to a contact, a project, a group, etc.
This isn’t to replace the whole file system, its just an indexing layer for your personal files, not the system files or programs.
I can’t wait to try it out.
Are you talking about Storage or WinFS? or both?
The Palm OS was designed, like OS 400, to contend primarily with fielded data. The Palm API provides access to databases rather than files (non-volatile storage cards are an exception) and maintains a management system (pointers, really) to write and retrieve records. Each record has an abritrary structure – it can vary from record to record. The records are a method for imposing some order on RAM. This is what Reiser FS 4 is about, as well. It works very well for most data applications (which are also ‘databases’ on a Palm).
I think the mentioned distributed nature of WinFS will probably be one of the most useful features. I think that metadata will be more useful for some formats than for others.
Atm mp3 and variants are the most common users of metadata, however as anyone knows that metadata is often incomplete or incorrect.
Auto tagging of files is only so useful and tagging thousands of files individually is not going to happen. With both storage and winfs I think the metadata functionality is hyped more than it should be. Most people I’ve seen don’t make a long term habit of filling out extra info fields in a meaninful way.
I guess in the long term M$ is going for a fully integrated system, one where programs can integrate a database with less fiddling about. Essentially the serialisation of file based data is hidden from the programmer. Kinda like single level storage similar to Os 400 perhaps (never used it myself)
but I’m pretty sure Longhorn will still have ordinary NTFS available for us organised skeptics.. however you will probably miss the fancy playlist thingamys
But having used database style filesystems, both under OS/400 and on my own machine thanks to BeOS…
I actually prefer a more conventional filesystem. Maybe it’s just the way my brain works, maybe I’ve just been using the ‘old way’ for too long, but to me, a normal filesystem with directories and file extensions just works better for me. To my brain it’s inefficient use of storage space for information I’m not going to use.
But then, I do this really retarded thing of putting files by subject in their appropriate directories, creating new directories as needed…
Call me old fashioned, but I don’t need anything fancier than a three letter extension to a file to tell me what it is. If anything, I would kill to be able to hack explorer under windows to replace ‘file type’ which is based on the associated program with the ACTUAL FILE EXTENSION.
Let’s face it, 90%+ of the viruses transmitted via e-mail or file sharing programs would not ever be communicated if the actual file extension was listed in a separate column, and the default behavior for winblows wasn’t to hide file extensions for known types. Oops, bye-bye people falling for .jpg.vbs
What in blazes is so wrong with using file extensions??? I find it a million times more versatile and faster to use than any of these fancy systems programmers seem willing to bend over backwards to implement these days.
But then, I’m the guy who has never EVER had reason to actually use the search feature on any OS.
That anonymous message mentions something on the same subject, and something I feel was a total waste of effort; the ID tags inside MP3’s. Most of the time the data is incorrect, or filled out wrong, or just plain redundant. What is wrong with putting the Band name, Album name, track number, and song title IN THE FILENAME!!! God, what a crazy idea.
Which is why ALL the MP3’s I have on my machine have their ID3 tags stripped out.
ITunes is a great micro-example (and Google a great macro-example) of how bad hierarchical data access sucks when you have lots of data (14 days of music on the MP3 drive), and how awesome unstructured queries are when you have rich meta-data. When I was using WinAmp and wanted to play the ‘Run Lola Run’ soundtrack I was screwed, because the the files were hierarchically organized by artist. Several artists (whom I’ve never heard of) contributed to that soundtrack. It took me some time to step through the hierarchy that wasn’t setup like I needed to find the right MP3s. Now I run ITunes. I just type key word ‘Lola’ into the search text field, and I get a view of the data I want. Later, I want a new view of the data, I just type in a new key word. I am more than willing to pay for gigabytes of meta-data to get that kind of dynamic view creation on all my data. Hierarchical data storage doesn’t scale to the amount of information we have today.
“Most of the time the data is incorrect, or filled out wrong, or just plain redundant. What is wrong with putting the Band name, Album name, track number, and song title IN THE FILENAME!!! God, what a crazy idea.”
What does it matter where the data is if it’s incorrect? Better to store it in a way so that it’s all mixed up and only human-readable (and not queriable)? What’s so special about the filename? Would you want a whole wordocument in the filename? Why not?
Have you tried “j” in winamp? Works quite well actually.
(Oh, and I agree that rich metadata + queries = awesome.)
To be honest, I wasn’t concentrating not so much upon metadata, but the storage of the data itself; although hopefully both WinFS and Storage will help with both to varying degrees.
I don’t know about you deathshadow, but I sure wouldn’t want files named like:
SomeArtist – SomeSong – SomeAlbum – Track – Year – Genre – Length – Rating – Comment – Bitrate.mp3
I try to keep my filenames shorter than 100 chars. Also, keeping all the info in the filename just makes it too difficult to sort the music.
I do however also think that ID3 tags are evil. Long live BFS attributes!
> > 2. How will I restore these kinds of backups? Will I be able to
> > restore this data on my other computers? What if my other
> > computers are running OS X or BSD or Linux?
> Being NTFS, actual files will still be readable under linux with the
> exisiting NTFS driver. The database meta-data and relationships will
> not be accessible and some of the files might be hard to find since
> they may not be stored in hierachical folders and may have filenames
> generated at random. eg GUIDs
This suggests that files are still stored in NTFS and that there is a separate DB store with the metadata. Do you have a reference to a description of this scheme? I understood that files were stored in the DB store as BLOBs and that the DB store was going to be one or more files in NTFS. But I could be wrong, and I don’t have access to a Longhorn system.
Ok, maybe I’m out there, again, but I don’t tend to give a @#$!% about Genre, I can usually figure the length by filesize, since I tend to not HAVE any files that aren’t 44khz 16 bit (I delete anything faster, and anything lower quality I usually delete in favor of a CD rip), ignore ratings and comments (since I usually disagree with other people’s anyways)…..
I mean, I don’t care about any of that; I just want to listen to the damn thing. A 30-50 character filename is fine for that; unless you get a band that does something wacko and has a 50 character album name.
As to too difficult to sort; sort by alpha, it separates by artist, then the album; assuming you take the time to name the files right in the first place.
Typical filenames:
Omar&TheHowlers_TheScreamingCat_01_When Sugar Cane Was King.MP3
Omar&TheHowlers_TheScreamingCat_02_The Screaming Cat.MP3
Omar&TheHowlers_TheScreamingCat_03_100 pounds of Pain.MP3
I dunno, I have no problems with that, and don’t need more than it. Works even better in detail view; sorted by name; instead of that stupid malfin iconic view which is next to useless for most everything other than jpegs.
Maybe they need something more lightweight.
http://xml.apache.org/xindice/
http://tm4j.org/
People seem to forget to mention this product, which has the central storage and metadata support mentioned above.
What doesn’t Microsoft build into it prottective memory and make multi-user like UNIX. They can trash .dll and their security holes registry. They can get rid their infamous 64K stake and DOS. Who cares about a sql FS. Gee, when did os 400 become popular? And the BeOS…well, as much as I liked it, be failed to deliver.
Actually, the concept of DB storage goes back to 1965 when TRW developed a system for the US Army that was later commercialized by Dick Pick. Here is a list of the most relevant implemantations of Pick. The original which is now called D3 (Raining Data) UniVerse and UniData (IBM which accounts for the lions share of the market. Also called U2)jBASE, Reality (Northgate) and UniVision (EDP) . Revelation and APPGEN could also be included in this group.
Applications among these versions of Pick are typically very portable often requiring no more than doing a back-up on one system and restoring it on the other.
Henry Keultjes
Database Scientifics
Mansfield Ohio USA
How about Reiser4, it’s not a DB, but it has features that will make a lot of things possible. Also it will support plugins so that new features could be added to the FS while still it’ll be a normal FS at the bottom.
In my oppinion Reiser4 will be a better sollution to WinFS.