> 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. _______________________________________________ Gnu-arch-users mailing list [email protected] http://lists.gnu.org/mailman/listinfo/gnu-arch-users GNU arch home page: http://savannah.gnu.org/projects/gnu-arch/
