From mboxrd@z Thu Jan 1 00:00:00 1970 Message-ID: <492A88DD.2070900@proweb.co.uk> Date: Mon, 24 Nov 2008 10:58:37 +0000 From: matt User-Agent: Icedove 1.5.0.14eol (X11/20080724) MIME-Version: 1.0 To: Fans of the OS Plan 9 from Bell Labs <9fans@9fans.net> References: <20081123220653.GA25062@nibiru.local> In-Reply-To: <20081123220653.GA25062@nibiru.local> Content-Type: text/plain; charset=ISO-8859-1; format=flowed Content-Transfer-Encoding: 7bit Subject: Re: [9fans] dbfs and web framework for plan 9 Topicbox-Message-UUID: 515f0bb2-ead4-11e9-9d60-3106f5b1d025 > That's exactly what constraints, rules in SQL etc are for. > Maybe some similar ruling system for filesystems would be fine :) > (any suggestions ?) > That's what I was driving at. To map SQL <> FS you end up replicating lots of SQL logic in your client FS. Reads are *always* out of date. Writes can happen across tables but need to be atomic and able to roll back. Funny you should mention rules for filesystems. I also did the opposite and wrote a front end that mapped 9p onto SQL. I.E. a scehma that represented a file system with QIDs etc. with a python marshaller inbetween such that Postgres was the backing store for 9p. I got a bit stuck when the file sizes got over the row size, the blob spec wasn't very clearly documented to me; all you get is the C function definitions rather than what goes over the wire so it's another project in the unfinished pile :) I've got a few weeks off soon and I'm going to revisit my py9p :)