First of all... Thanks for your reply! I hope we could continue this brainstorm... it was really useful for me.
On Fri, Nov 21, 2008 at 12:18 AM, Skip Tavakkolian <[EMAIL PROTECTED]> wrote: > > - provide access to relational database towards a dedicated fs (with > XML > > rappresentation of query results, but dont know yet about data > manipulation > > and error handling) > > an rdbms interface will be messy; maybe just try to get a ODBC client > library. most of the time what is really needed is fast lookup; > something like PQ would do. a lot of places use DB to store things > that naturally belong in a file heirarchy. May be. But there are also (many? here where I work it's so!) place where datas (and their relations) MUST be kept consistents. And MUST be updated frequently, in transaction. Application code cannot do that, since it's too subject to modifications (and this for complex applications lead to inevitable bugs which must not corrupt datas). Moreover such a dbfs should allow rapid development of views over data (with different permissions) by simply write the query in a file and then open the file for reading the XML. > > - provide a filesystem capable of transform an XML file with an XSLT > > template, so that dbfs and rest webservices could be handled the same > way. > > i see these as filters used by filterfs. the filter to file mapping > might be doable using plumber. Right... the could be seen so (but what about caching results?). plumber is still black magic for me... dirty lunix user... :-D > > - glue all together with a set of filesystem/applications able to > handle > > the business logic (for example a simpe ecommerce would have a > cataloguefs > > and a shoppingcartfs) rapidly written towards a dedicated library (may > be > > something like your cgifs?) > > it's easy to develop libraries for cgifs. it's all in rc. if you > need something special, write a C utility that does the > specific thing. Good! ! ! The example you provided show exactly what I need to know about cgifs. But not exactly what I think, since as I could understand, cgifs applications dont keep state during the user session. I mean that, in the simple ecommerce example, the shoppingcartfs is an application than handle the shopping cart for each particular session, and it's started (= mounted) when a new client connect and closed when the session timeout. >From a OO prespective each such filesystem are Objects handling Models. Writing to shoppingcartfs/add something like AB123123|20 would add a 20 item with code AB123123, updating the totals. Then by reading shoppingcartfs/status, you would get all the info you need (in XML) in the next requests from that client. Note that those XML could be handled locally by the server (building HTML for the client) or sent to the client as it is, if _that_ client support ajax and xslt transformations, moving part of the computation there. If Javascript was disabled (suppose for blind's software reading the page), all will work. > > - provide a "sessionfs" able to mount (unmount would be necessary? I > > think so...) the correct filesystems/applications for each visitor. > > srvfs posted to /srv will do; a httpd running with the proper > permissions wont have a problem mounting what's posted in /srv. what > i have in mind for sessionfs is to keep a stateless http session > (using session id's that are consecutive and time sensitive) to carry > a conversation with factotum. :-o Could you repeat in Klingon, please? :-D Ok... I have to study (quite) a bit more... :-D My (from 10000 foot) idea of a sessionfs is to enable the httpd to send all the request coming from a given client to some particular temporary dir where all the application/filesystems are mounted for that particular client session. This way once mounted, the applications/fs/objects (as you like so see them) are absolutely stateful, even if the protocol is stateless. Factotum and /srv/ could do this? > fyi, here's the rc version of 'save' that uses cgifs: > > Wondefully simple. The only issue is the programmer have to handle directly the protocol (as in any CGI). I'd like to abstract a little more. Thank you a lot if you read till here! :-D Giacomo
