Re: [Gnu-arch-users] file system interface to a database

[Alfred M\. Szmidt]

   > I disagree, strongly.  TLA should not even have a notion of a
   > backend.  It should only need a notion of `file-system
   > operations'.  Then if you want to use SQL as your file-system,
   > you simply mount it.  Solutions like these are very short
   > sighted.

   Perhaps backend is not the good word to designate what I'm
   thinking.  Actually, tla is aware of how data are stored, archives
   implementation use directly the notion of file and directory.  What
   I suggest is to have a layer in order that tla code don't need to
   know how data is stored.

I still don't think it is a bright idea to make it so abstract that it
hides open/read/write/close, if that is your plan.

   What can bring this model, a good preparation to implement other
   way to store data, that can improve for example windows
   compatibility.

Personally, I don't think that is all that important, tla already runs
in cygwin from what I know.  If it doesn't, that is the furthest we
should go with Windows compatibility IMHO.

   For the corruption, db engine are designed not to corrupt the data
   even if the software crash during a writing operation.  I don't say
   that a corruption of a database never happen, but this is not a
   very common situation.

I have been screwed over by faulty ext2 drivers, crashed file-systems,
and what not far more often than a faulty SQL database.  The claim
that somehow a file-system is better suited for critical data is
completley false, and from my extensive experience of being screwed
over, it is the complete and utter opposite.  File-systems are
inherently more complex than databases.


Cheers.