Pavlos:
On Tue, 2 May 2000, Lalo Martins wrote:
Still I'd like to see a "filesystem directory tree storage" (but what about version control? Undo? The whole transaction infrastructure?)
That would be the difficult part. I suppose one way is to use the 'spare' attributes on some new filesystems to store transaction ids. Then commands like rm/mv/cp etc will be replaced with their transactional versions so they will ensure transactional integrity. In other words I have no clue ...
Me neither in that respect.
Regarding archiving and distributing Data.fs files very efficient algorithms specific to Data.fs can be written.
This is what I'm talking about. Splitting the Data.fs into pieces and maybe even each object has it's own piece with revisions of that object stored in it's piece. This offers some interesting pluses. Anyone see anything really glaringly wrong with this?
As Data.fs only appends data (with the exception of packing) one can quickly locate any new appends (based on transaction ids) and distribute them to different servers. Additionaly the changes can be stored incrementaly so you could recreate a Data.fs file for a specified date.
Oooh.
I really wished I had some time to work on it ... I don't thing it would be very diffult. In other words I am clueless again ...
I am just finishing the "learning Python" O'Reilly book (just to let you know where my skills are) But this sounds too interesting not to try. Again, does anyone see anything glaringly wrong with this? All my best, Jason Spisak CIO HireTechs.com 6151 West Century Boulevard Suite 900 Los Angeles, CA 90045 P. 310.665.3444 F. 310.665.3544 Under US Code Title 47, Sec.227(b)(1)(C), Sec.227(a)(2)(B) This email address may not be added to any commercial mail list with out my permission. Violation of my privacy with advertising or SPAM will result in a suit for a MINIMUM of $500 damages/incident, $1500 for repeats.