* [9fans] web-based plan 9? @ 2008-11-20 1:35 Pietro Gagliardi 2008-11-20 14:25 ` Eric Van Hensbergen 0 siblings, 1 reply; 25+ messages in thread From: Pietro Gagliardi @ 2008-11-20 1:35 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs -----BEGIN PGP SIGNED MESSAGE----- Hash: SHA1 Take a look at this: http://www.blazebyte.org/gnextop/ It runs a complete Linux system in a web browser, so users of the PlayStation Portable can finally write software for it without fear of being bricked by Sony's anti-piracy measures. Can Plan 9 have this? I don't mean like Inferno grid, I mean like drawterm in Java. -----BEGIN PGP SIGNATURE----- Version: GnuPG v1.4.8 (Darwin) iEYEARECAAYFAkkkvsgACgkQuv7AVNQDs+z6lQCfdSx87t4dA48MYZwmXipF6NdX iGgAnjKvlW+udMPyK2UYn89QQ+m8ybPw =+Ify -----END PGP SIGNATURE----- ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] web-based plan 9? 2008-11-20 1:35 [9fans] web-based plan 9? Pietro Gagliardi @ 2008-11-20 14:25 ` Eric Van Hensbergen 2008-11-20 14:37 ` Fco. J. Ballesteros 2008-11-20 18:59 ` Skip Tavakkolian 0 siblings, 2 replies; 25+ messages in thread From: Eric Van Hensbergen @ 2008-11-20 14:25 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Wed, Nov 19, 2008 at 7:35 PM, Pietro Gagliardi <pietro10@mac.com> wrote: > Take a look at this: > > http://www.blazebyte.org/gnextop/ > > It runs a complete Linux system in a web browser, so users of the > PlayStation Portable can finally write software for it without fear of being > bricked by Sony's anti-piracy measures. > > Can Plan 9 have this? I don't mean like Inferno grid, I mean like drawterm > in Java. > I've toyed with the idea of a webtop interface to Inferno (that I suppose could easily have a similar implementation on Plan 9): http://graverobbers.blogspot.com/2008/04/service-oriented-file-systems.html I'm sure the Plan B/Octopus guys have some thoughts here as well. -eric ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] web-based plan 9? 2008-11-20 14:25 ` Eric Van Hensbergen @ 2008-11-20 14:37 ` Fco. J. Ballesteros 2008-11-20 14:47 ` Eric Van Hensbergen 2008-11-20 14:51 ` erik quanstrom 2008-11-20 18:59 ` Skip Tavakkolian 1 sibling, 2 replies; 25+ messages in thread From: Fco. J. Ballesteros @ 2008-11-20 14:37 UTC (permalink / raw) To: 9fans We had a prototype that tried to reproduce in a web page the UI structure as described by o/mero. Nothing that really could be used in practice. In the end we abandoned that and used inferno for the client software (terminal). It's funny the post about using Sepxs to transfer FS trees, because that's quite similar to what o/mero does to send updates to the viewer, o/live. It sends a batch of the UI tree that changed. Anyone experimented with providing this as a general feature for a FS? (I think I understood that in one of the posts, but I'm not sure). > From: ericvh@gmail.com > To: 9fans@9fans.net > Reply-To: 9fans@9fans.net > Date: Thu Nov 20 15:26:39 CET 2008 > Subject: Re: [9fans] web-based plan 9? > > On Wed, Nov 19, 2008 at 7:35 PM, Pietro Gagliardi <pietro10@mac.com> wrote: > > Take a look at this: > > > > http://www.blazebyte.org/gnextop/ > > > > It runs a complete Linux system in a web browser, so users of the > > PlayStation Portable can finally write software for it without fear of being > > bricked by Sony's anti-piracy measures. > > > > Can Plan 9 have this? I don't mean like Inferno grid, I mean like drawterm > > in Java. > > > > I've toyed with the idea of a webtop interface to Inferno (that I > suppose could easily have a similar implementation on Plan 9): > > http://graverobbers.blogspot.com/2008/04/service-oriented-file-systems.html > > I'm sure the Plan B/Octopus guys have some thoughts here as well. > > -eric ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] web-based plan 9? 2008-11-20 14:37 ` Fco. J. Ballesteros @ 2008-11-20 14:47 ` Eric Van Hensbergen 2008-11-20 15:07 ` Fco. J. Ballesteros 2008-11-20 14:51 ` erik quanstrom 1 sibling, 1 reply; 25+ messages in thread From: Eric Van Hensbergen @ 2008-11-20 14:47 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Thu, Nov 20, 2008 at 8:37 AM, Fco. J. Ballesteros <nemo@lsub.org> wrote: > We had a prototype that tried to reproduce in a web page > the UI structure as described by o/mero. > > Nothing that really could be used in practice. > In the end we abandoned that and used inferno for > the client software (terminal). > Were you using draw-like-primitives or browser-like primitives for the UI? -eric ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] web-based plan 9? 2008-11-20 14:47 ` Eric Van Hensbergen @ 2008-11-20 15:07 ` Fco. J. Ballesteros 2008-11-20 15:16 ` Eric Van Hensbergen 0 siblings, 1 reply; 25+ messages in thread From: Fco. J. Ballesteros @ 2008-11-20 15:07 UTC (permalink / raw) To: 9fans browser like. > From: ericvh@gmail.com > To: 9fans@9fans.net > Reply-To: 9fans@9fans.net > Date: Thu Nov 20 15:50:20 CET 2008 > Subject: Re: [9fans] web-based plan 9? > > On Thu, Nov 20, 2008 at 8:37 AM, Fco. J. Ballesteros <nemo@lsub.org> wrote: > > We had a prototype that tried to reproduce in a web page > > the UI structure as described by o/mero. > > > > Nothing that really could be used in practice. > > In the end we abandoned that and used inferno for > > the client software (terminal). > > > > Were you using draw-like-primitives or browser-like primitives for the UI? > > -eric ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] web-based plan 9? 2008-11-20 15:07 ` Fco. J. Ballesteros @ 2008-11-20 15:16 ` Eric Van Hensbergen 2008-11-20 15:21 ` Francisco J Ballesteros 0 siblings, 1 reply; 25+ messages in thread From: Eric Van Hensbergen @ 2008-11-20 15:16 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Thu, Nov 20, 2008 at 9:07 AM, Fco. J. Ballesteros <nemo@lsub.org> wrote: > browser like. > I'd be interested in seeing what you guys had done if you had tar-balls or something of it laying around.... -eric ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] web-based plan 9? 2008-11-20 15:16 ` Eric Van Hensbergen @ 2008-11-20 15:21 ` Francisco J Ballesteros 0 siblings, 0 replies; 25+ messages in thread From: Francisco J Ballesteros @ 2008-11-20 15:21 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs It was a disaster. Just an adhoc script to reproduce the structure from the file tree in omero in the browser. In any case, I'm not sure where the source might be. I'll take a look and drop you a line if I find it out. On Thu, Nov 20, 2008 at 4:16 PM, Eric Van Hensbergen <ericvh@gmail.com> wrote: > On Thu, Nov 20, 2008 at 9:07 AM, Fco. J. Ballesteros <nemo@lsub.org> wrote: >> browser like. >> > > I'd be interested in seeing what you guys had done if you had > tar-balls or something of it laying around.... > > -eric > > ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] web-based plan 9? 2008-11-20 14:37 ` Fco. J. Ballesteros 2008-11-20 14:47 ` Eric Van Hensbergen @ 2008-11-20 14:51 ` erik quanstrom 1 sibling, 0 replies; 25+ messages in thread From: erik quanstrom @ 2008-11-20 14:51 UTC (permalink / raw) To: 9fans > It's funny the post about using Sepxs to transfer > FS trees, because that's quite similar to what o/mero > does to send updates to the viewer, o/live. > It sends a batch of the UI tree that changed. it was a slightly different format, but i believe we used to call this trick "tar". ☺ - erik ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] web-based plan 9? 2008-11-20 14:25 ` Eric Van Hensbergen 2008-11-20 14:37 ` Fco. J. Ballesteros @ 2008-11-20 18:59 ` Skip Tavakkolian 2008-11-20 19:25 ` Skip Tavakkolian 2008-11-20 22:15 ` Giacomo Tesio 1 sibling, 2 replies; 25+ messages in thread From: Skip Tavakkolian @ 2008-11-20 18:59 UTC (permalink / raw) To: 9fans > I've toyed with the idea of a webtop interface to Inferno (that I > suppose could easily have a similar implementation on Plan 9): > > http://graverobbers.blogspot.com/2008/04/service-oriented-file-systems.html > > I'm sure the Plan B/Octopus guys have some thoughts here as well. we're slowly working toward that for rangboom. we use Yahoo's YUI js libraries. they encapsulate many useful js widgets like rich text editor, menus, etc.. for rangboom, once the user is logged in from the web interface it's basically javascript and xml (because all browser/js can grok xml). the javascript in the namespace page includes the full "api". this is what is needed (and worked on): cgifs: mostly done thanks to fgb. i'll put it up soon. rit: already available thanks to kenji filterfs: sythesize a filesystem from other fs and rc filters. could use exportfs as a start. design in mind, no code yet. at one point ehg mentioned such a thing at Labs. sessionfs: keep continuity of http session for factotum. design in mind, no code yet. httpd: modifications similar to pegasus to start httpd for an authenticated user with that user's credentials. not done. with filterfs in place one can generate bits of js code along with html for the type of files being accessed, or views being looked at; but would still require a good bit more js code. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] web-based plan 9? 2008-11-20 18:59 ` Skip Tavakkolian @ 2008-11-20 19:25 ` Skip Tavakkolian 2008-11-20 22:15 ` Giacomo Tesio 1 sibling, 0 replies; 25+ messages in thread From: Skip Tavakkolian @ 2008-11-20 19:25 UTC (permalink / raw) To: 9fans just to be clear, i think webtop or web based approach is a backward step (or at least a side step). the whole point of plan9 is to represent everything as a namespace; in rangboom it means representing distant filesystems in the native form, hence use of windows IFS and FUSE for Linux and Mac. this would let the user use their existing applications. some users have a prejudice: they like to see anything that is not local inside the browser. a browser is also the only option for most mobile devices and kiosks. so, some web access is needed. >> I've toyed with the idea of a webtop interface to Inferno (that I >> suppose could easily have a similar implementation on Plan 9): >> >> http://graverobbers.blogspot.com/2008/04/service-oriented-file-systems.html >> >> I'm sure the Plan B/Octopus guys have some thoughts here as well. > > we're slowly working toward that for rangboom. we use Yahoo's YUI js > libraries. they encapsulate many useful js widgets like rich text > editor, menus, etc.. for rangboom, once the user is logged in from > the web interface it's basically javascript and xml (because all > browser/js can grok xml). the javascript in the namespace page > includes the full "api". > > this is what is needed (and worked on): > > cgifs: mostly done thanks to fgb. i'll put it up soon. > rit: already available thanks to kenji > filterfs: sythesize a filesystem from other fs and rc filters. could use > exportfs as a start. design in mind, no code yet. at one > point ehg mentioned such a thing at Labs. > sessionfs: keep continuity of http session for factotum. > design in mind, no code yet. > httpd: modifications similar to pegasus to start httpd for an authenticated > user with that user's credentials. not done. > > with filterfs in place one can generate bits of js code along with > html for the type of files being accessed, or views being looked > at; but would still require a good bit more js code. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] web-based plan 9? 2008-11-20 18:59 ` Skip Tavakkolian 2008-11-20 19:25 ` Skip Tavakkolian @ 2008-11-20 22:15 ` Giacomo Tesio 2008-11-20 23:18 ` Skip Tavakkolian 1 sibling, 1 reply; 25+ messages in thread From: Giacomo Tesio @ 2008-11-20 22:15 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 2629 bytes --] > > cgifs: mostly done thanks to fgb. i'll put it up soon. > rit: already available thanks to kenji > filterfs: sythesize a filesystem from other fs and rc filters. could use > exportfs as a start. design in mind, no code yet. at one > point ehg mentioned such a thing at Labs. > sessionfs: keep continuity of http session for factotum. > design in mind, no code yet. > httpd: modifications similar to pegasus to start httpd for an authenticated > user with that user's credentials. not done. > > with filterfs in place one can generate bits of js code along with > html for the type of files being accessed, or views being looked > at; but would still require a good bit more js code. > > > I'm really interessed in it. I'm thinking about something similar (pegasus based) to build a web framewok quite particular. I'm in the study/design stage (and actually I dont master Plan 9 development itself) but I'm sure that to be useful it must: - 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) - 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. - provide a filesystem able to transform a TAL (tag attribute language) template to XSLT, allowing graphic designer to directly transform the data provided by programmers in XML without knowing XSLT (just tal and eventually xpath) - implement url rewrite (if missing) - 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?) - provide a "sessionfs" able to mount (unmount would be necessary? I think so...) the correct filesystems/applications for each visitor. I'd really like to take a look to your code / design (time permitting... I've got a daughter... monopolizing my wife... those are hard times... :-D) to get inspired/build upon that. I know about RIT, and I think that it could be good for filling/merging xml "templates", but not as a template language itself... As the smarty template engine shown to php programmers, even easy programming language has to be put outside the "presentation layer". Actually I have to study factotum more since I could not understand how you want to use it in a web environment. Giacomo Giacomo [-- Attachment #2: Type: text/html, Size: 3032 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] web-based plan 9? 2008-11-20 22:15 ` Giacomo Tesio @ 2008-11-20 23:18 ` Skip Tavakkolian 2008-11-21 5:19 ` lucio 2008-11-21 10:15 ` Giacomo Tesio 0 siblings, 2 replies; 25+ messages in thread From: Skip Tavakkolian @ 2008-11-20 23:18 UTC (permalink / raw) To: 9fans > - 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. > - 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. > - provide a filesystem able to transform a TAL (tag attribute language) > template to XSLT, allowing graphic designer to directly transform the data > provided by programmers in XML without knowing XSLT (just tal and eventually > xpath) > - implement url rewrite (if missing) > - 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. > - 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. fyi, here's the rc version of 'save' that uses cgifs: #!/bin/rc . /lib/cgifs/sandbox fn logit { echo $* > log } switch (`{cat request/method}) { case GET POST foo=`{cat request/info} if (! ~ $#foo 0) { foo=`{echo $foo | sed 's/^.//'} logit $foo foo=`{basename $foo '.html'} logit $foo if (test -f /www/save/^$foo^'.data') { bar=$foo^'.data' foo=$foo^'.html' switch (`{cat request/method}) { case POST str = `{cat request/body} case * str = `{cat request/query} } echo at `{date -n} $str >> /www/save/^$bar rit -D /www/save/^$foo > response/body } if not { echo $foo does not exist > response/body } } echo -n text/html > response/content-type echo -n 200 OK > response/reply case * echo -n text/html > response/content-type echo -n 405 Method Not Allowed > response/reply } exit 0 ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] web-based plan 9? 2008-11-20 23:18 ` Skip Tavakkolian @ 2008-11-21 5:19 ` lucio 2008-11-21 10:15 ` Giacomo Tesio 1 sibling, 0 replies; 25+ messages in thread From: lucio @ 2008-11-21 5:19 UTC (permalink / raw) To: 9fans > fyi, here's the rc version of 'save' that uses cgifs: > > #!/bin/rc > > . /lib/cgifs/sandbox May I humbly submit that the above is inadequate? I risk sounding like a serious newbie, but I believe that perhaps 9fans is too broad a vehicle to do Plan 9 justice. In this case, Skip's posting is extremely useful to those who already have a grasp of Plan 9's philosophy, but may be a little too cerebral to those who expect to learn about Plan 9 on this list. As somebody who discovers almost daily how much more there is to Plan 9 than I have been exposed to, I often wish a snippet of code was annotated with highlights for the specific information it is meant to illustrate. Of course this is not essential and some effort will disclose the details, but I'm almost certainly not the only person who does not always have the luxury to analyse a posting in such detail. Now, the intended recipient of the posting is almost certainly going to go to that effort out of necessity, but other interesting parties may sadly miss some important feature because of a lack of immediate interest. Of course, just like source code, annotations can be contributed by the community, not necessarily by the original poster, my intention here is merely to bring to the list's attention a possible shortcoming of the underlying culture on 9fans in the hope that others and also myself can address such a shortcoming. No disrespect intended towards Skip or his posting, it was merely the trigger that made me think along these lines. I must confess I had never perceived things in this light before. Nor do I think that I have a ready answer or even a sensible question, I'm merely voicing a fresh perception. ++L PS: I would like to see that Plan 9 FAQ re-appear, I believe it is sorely missed. Are there any volunteers to assist in reconstructing and maintaining it? ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] web-based plan 9? 2008-11-20 23:18 ` Skip Tavakkolian 2008-11-21 5:19 ` lucio @ 2008-11-21 10:15 ` Giacomo Tesio 2008-11-21 11:55 ` matt 2008-11-21 18:12 ` a 1 sibling, 2 replies; 25+ messages in thread From: Giacomo Tesio @ 2008-11-21 10:15 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 4412 bytes --] 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 <9nut@9netics.com> 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 [-- Attachment #2: Type: text/html, Size: 5701 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] web-based plan 9? 2008-11-21 10:15 ` Giacomo Tesio @ 2008-11-21 11:55 ` matt 2008-11-21 14:01 ` Tom Lieber 2008-11-21 18:12 ` a 1 sibling, 1 reply; 25+ messages in thread From: matt @ 2008-11-21 11:55 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > > 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. > I've tried a couple of times to map files / directories on to SQL and it is not a great match imho. I wrote a Limbo module that handles the postgresql protocol and frankly that's as far as I thought it should be taken, writes are one time use and any returned qureries are (potentially) outdated by the time the client gets them. Any FS would end up as a read only cache with somewhere to send sql writes and a load of logic that repeats what's on the SQL server already. I split my system into two - one to deal with the SQL and one that makes a FS tree from columnated data. Though I abandoned dev on the tree because I just ended up accessing the data through the Limbo pg module directly. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] web-based plan 9? 2008-11-21 11:55 ` matt @ 2008-11-21 14:01 ` Tom Lieber 2008-11-21 14:34 ` matt 0 siblings, 1 reply; 25+ messages in thread From: Tom Lieber @ 2008-11-21 14:01 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On Fri, Nov 21, 2008 at 6:55 AM, matt <mattmobile@proweb.co.uk> wrote: > I've tried a couple of times to map files / directories on to SQL and it is > not a great match imho. > > I wrote a Limbo module that handles the postgresql protocol and frankly > that's as far as I thought it should be taken, writes are one time use and > any returned qureries are (potentially) outdated by the time the client gets > them. Any FS would end up as a read only cache with somewhere to send sql > writes and a load of logic that repeats what's on the SQL server already. > > I split my system into two - one to deal with the SQL and one that makes a > FS tree from columnated data. Though I abandoned dev on the tree because I > just ended up accessing the data through the Limbo pg module directly. How was the data more outdated than when you used pg directly? -- Tom Lieber http://AllTom.com/ ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] web-based plan 9? 2008-11-21 14:01 ` Tom Lieber @ 2008-11-21 14:34 ` matt 2008-11-21 15:13 ` Giacomo Tesio 0 siblings, 1 reply; 25+ messages in thread From: matt @ 2008-11-21 14:34 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs >> I split my system into two - one to deal with the SQL and one that makes a >> FS tree from columnated data. Though I abandoned dev on the tree because I >> just ended up accessing the data through the Limbo pg module directly. >> > > How was the data more outdated than when you used pg directly? > > It's not that is was more outdated, it's that all the extra work to make it an FS was untapped because instead of writing a Limbo app to use a file system I ended up just adding the PGmodule to the app instead. I realise that exporting and mounting would be facilitated by the FS layer but I didn't have any reason to exploit such availablility. Basically I got as far as saying to myself - this will buy me nothing more than I have already so I'll just stop, one fo these days I might do the FS side of it, maybe. ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] web-based plan 9? 2008-11-21 14:34 ` matt @ 2008-11-21 15:13 ` Giacomo Tesio 2008-11-21 15:53 ` matt 0 siblings, 1 reply; 25+ messages in thread From: Giacomo Tesio @ 2008-11-21 15:13 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 850 bytes --] > I ended up just adding the PGmodule to the app instead. You used libpq to write such a PGmodule? I worked with PostgreSQL for 6 year... I find it wonderfull, and I would use it as the db backend for any opensource application I would write. > I realise that exporting and mounting would be facilitated by the FS layer > but I didn't have any reason to exploit such availablility. > > Basically I got as far as saying to myself - this will buy me nothing more > than I have already so I'll just stop, one fo these days I might do the FS > side of it, maybe. > I'd like to know how do you would map the operations to the filesystem. Query result in a filesystem hierachy would be a pain... xml would be better, since you could transform it quickly. BTW, there should be an xmlfs project waiting somewhere... Giacomo [-- Attachment #2: Type: text/html, Size: 1226 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] web-based plan 9? 2008-11-21 15:13 ` Giacomo Tesio @ 2008-11-21 15:53 ` matt 2008-11-21 16:05 ` erik quanstrom 2008-11-21 17:05 ` Giacomo Tesio 0 siblings, 2 replies; 25+ messages in thread From: matt @ 2008-11-21 15:53 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > You used libpq to write such a PGmodule? No I didn't use libpq, I wrote the client from the protocol spec http://www.postgresql.org/docs/8.3/static/protocol.html These are the latest ones online http://plan9.bell-labs.com/sources/contrib/maht/limbo/module/pg.m http://plan9.bell-labs.com/sources/contrib/maht/limbo/appl/lib/pg.b though this looks a bit older http://plan9.bell-labs.com/sources/contrib/maht/limbo/pg/ the web interface is screwy so I gave up checking the differences :) > > I'd like to know how do you would map the operations to the filesystem. > one directory per queryset row returned (possibly named by the primary key), one file per column > Query result in a filesystem hierachy would be a pain... xml would be > better, since you could transform it quickly. > BTW, there should be an xmlfs project waiting somewhere... ah xml, the ultimate 2d grid ! xmlfs is a pain because it has anonymous entries so you need a way of organising it <xml> <a><b>123</b></a> <a><b>456</b></a> </xml> when you do an ls you have to arrange 123 to appear in your listing before 456 plus <a><b /></a> is not the same as <a> <b /> </a> ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] web-based plan 9? 2008-11-21 15:53 ` matt @ 2008-11-21 16:05 ` erik quanstrom 2008-11-21 17:05 ` Giacomo Tesio 1 sibling, 0 replies; 25+ messages in thread From: erik quanstrom @ 2008-11-21 16:05 UTC (permalink / raw) To: 9fans > xmlfs is a pain because it has anonymous entries so you need a way of > organising it > > <xml> > <a><b>123</b></a> > <a><b>456</b></a> > </xml> once upon a time, when god was a small boy i worked on a distributed search product. the search engine we were using was OpenText whose chief tech guy was (drumroll) tim bray. ot returned hitlists as byte offsets encoded in (oh, you'll never guess) xml. i don't recall the formatting exactly, but a hitlist looked something like <hitlist><hit><start>2313131</start><end>2313138</end></hit>... one can imagine that using careful formatting to increase the amount of data that needed to be moved by an order of magnitude resulted in spectacular performance. ah, the good old days. - erik ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] web-based plan 9? 2008-11-21 15:53 ` matt 2008-11-21 16:05 ` erik quanstrom @ 2008-11-21 17:05 ` Giacomo Tesio 2008-11-21 17:18 ` erik quanstrom 2008-11-21 17:24 ` matt 1 sibling, 2 replies; 25+ messages in thread From: Giacomo Tesio @ 2008-11-21 17:05 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs [-- Attachment #1: Type: text/plain, Size: 1458 bytes --] > > I'd like to know how do you would map the operations to the filesystem. >> >> > one directory per queryset row returned (possibly named by the primary > key), one file per column > Ok... I read it somewhere in the archives of the list. But I found it a little "inadeguate": - what about multiple fields primary key? - what about transactions? - what data modifications (insert update delete)? 'till now I imagine it so: opening a transaction could be creating a directory on a dbfs/transactions/ each of such directories (like the complete connection) has - a "ctrl" file which accept only COMMIT, ROLLBACK and ABORT - an "error" file - a "notice" file (postgresql has RAISE NOTICE... may be others have it too) - a "data" file (append only in the transaction, but not outside) where the INSERT, UPDATES, DELETE and all the DDL and DCL commands will be written - each SELECT have to be written in a different file (named sequentially): after writing the query, the same file could be read to get the results (in xml...) - on errors, sequents writes fails and error file will be readable > > Query result in a filesystem hierachy would be a pain... xml would be >> better, since you could transform it quickly. >> BTW, there should be an xmlfs project waiting somewhere... >> > > ah xml, the ultimate 2d grid ! I'm missing what you mean. xlmfs is bugged? Giacomo [-- Attachment #2: Type: text/html, Size: 2276 bytes --] ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] web-based plan 9? 2008-11-21 17:05 ` Giacomo Tesio @ 2008-11-21 17:18 ` erik quanstrom 2008-11-22 20:15 ` Giacomo Tesio 2008-11-21 17:24 ` matt 1 sibling, 1 reply; 25+ messages in thread From: erik quanstrom @ 2008-11-21 17:18 UTC (permalink / raw) To: 9fans > - a "ctrl" file which accept only COMMIT, ROLLBACK and ABORT > - an "error" file > - a "notice" file (postgresql has RAISE NOTICE... may be others have it > too) > - a "data" file (append only in the transaction, but not outside) where > the INSERT, UPDATES, DELETE and all the DDL and DCL commands will be written > - each SELECT have to be written in a different file (named databases seem pretty far outside 9fans territory and design on a mailing list doesn't seem like a good idea ... but anway, i hope this comment is more strategy than design and a bit more general. since a relational database isn't imperative thing, i have never understood having a imperative interface to one, especially an unconstrained interface. if you have a problem big enough to warrant a database, it will get refactored, rekeyed, renormaled &c. it's quite unattractive to have a database reorganization escape and force changes in imperative code. i think a declarative interface would make much more sense — as in i want a new user fred with properties x, y, z instead of begin transaction .... if you're going to put up with a database, it needs be a big boy and take care of itself. would you put up with a file system that required you to do the locking and inode allocation yourself? - erik ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] web-based plan 9? 2008-11-21 17:18 ` erik quanstrom @ 2008-11-22 20:15 ` Giacomo Tesio 0 siblings, 0 replies; 25+ messages in thread From: Giacomo Tesio @ 2008-11-22 20:15 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs On 11/21/08, erik quanstrom <quanstro@quanstro.net> wrote: > databases seem pretty far outside 9fans territory and design > on a mailing list doesn't seem like a good idea ... Excuse me... BTW, is there a mailing list to discuss such design problems? I could not be consider a Plan 9 user, yet, I've just studied it for a while. Proposing such a framework was a way to check my understanding, too. > since a relational database isn't imperative thing, i have never > understood having a imperative interface to one, especially an > unconstrained interface. if you have a problem big enough to > warrant a database, it will get refactored, rekeyed, renormaled &c. Still data conteined will be consistent. I would have a lot of work to do, but who would pay for my time would not loose it's informations. They will be differently organized, differetly used... ok. But "the problem", the new feature requested, is what HE need. (and, in the last 3 years, I've never got such a destructing refactoring in any of the database I designed - and they were not blog/toy db ;-D ) > ..it needs be a big boy and take care of itself. There are product/project where many different professions are needed. Even if I'm often a glue among different fields, no one could do everything alone. Different tiers allow different men to work together. That's why we use db. Moreover if a man commit an error, db constraints keep data safe. And who pay me could accept a bug in the software if his data (suppose the contability of a bank) are kept ok. > would you put up with a file system > that required you to do the locking and inode allocation yourself? Why? The question is not clear to me... > > - erik Giacomo ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] web-based plan 9? 2008-11-21 17:05 ` Giacomo Tesio 2008-11-21 17:18 ` erik quanstrom @ 2008-11-21 17:24 ` matt 1 sibling, 0 replies; 25+ messages in thread From: matt @ 2008-11-21 17:24 UTC (permalink / raw) To: Fans of the OS Plan 9 from Bell Labs > > Ok... I read it somewhere in the archives of the list. > > But I found it a little "inadeguate": me too, for all the reasons you listed, that's why I stopped. I learned the pg protocol and saw it didn't map very well. I couldn't see what one would gain over writing raw SQL to a file. Reading results back is a different problem. > > > ah xml, the ultimate 2d grid ! > > > I'm missing what you mean. XML is a tree format, SQL tables are multiple 2d grids. > xlmfs is bugged? Nope, ^ permalink raw reply [flat|nested] 25+ messages in thread
* Re: [9fans] web-based plan 9? 2008-11-21 10:15 ` Giacomo Tesio 2008-11-21 11:55 ` matt @ 2008-11-21 18:12 ` a 1 sibling, 0 replies; 25+ messages in thread From: a @ 2008-11-21 18:12 UTC (permalink / raw) To: 9fans On db ↔ fs conversions: // datas (and their relations) MUST be kept consistents. there's two things you could mean here: either the relations between the data fields/types or the relations between their values. SQL databases are interesting because they don't do anything to keep the relations consistent, at a schema level. there are some cases where this is valuable, but most of the time it just puts more of the burden on the application. enforcing consistency between values is a whole different matter. i don't think that belongs in the database layer of an application, but on the application side. why let the ap shove bad data at your DB? bad for scalability (if your DB is complex enough to need that kind of consistency checking, it's likely that it's a performance bottleneck alread), bad for security/stability (why let mallicious attackers fuzz your DB?), and largely needs to be done in the ap anyway (say your DB rejects a submission; are you just giong to panic, say "try again", or try and figure out what it didn't like?). // And MUST be updated frequently, in transaction. just curious: what is it about "transactionality" that you care about? atomicity, logging, roll-back (atomic roll-back)? // Application code cannot do that, since it's too subject to // modifications... i'm not convinced. you can simply... not modify it! unless you've got a database you're exposing to multiple parties and you're worried one is going to mess things up for others, but in that case i think exposing the database directly is pretty risky regardless. the application i've worked on with the most complex data constraints had an "ontology layer" that everything that wanted to do data access went through. the rest of the application got to ask very simple questions about what it wanted, or make very simple updates, and the ontology layer made sure everything was consistent before talking to the database. you get the benifits of having that work be centralized, not related to the core application logic (and thus not touched when ap logic changes), and you have a much better idea of what went wrong when a constraint failed. // 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. somewhere around here i've got a /chan/pq for inferno that makes connections to a pq database. each open is a new logical connection; you write the query and read the result. results were not in XML, and pq has no updates (at current). i think you've got some very interesting ideas on sessionfs in particular. i have more thinking to do there. oh, probably an aside: from an application design point of view, DO NOT empty my shopping cart just because my session timed out. i should be able to pick up where i left off. i'm not sure how hypothetical that example was, but that's a common source of irritation for online shopping. ^ permalink raw reply [flat|nested] 25+ messages in thread
end of thread, other threads:[~2008-11-22 20:15 UTC | newest] Thread overview: 25+ messages (download: mbox.gz / follow: Atom feed) -- links below jump to the message on this page -- 2008-11-20 1:35 [9fans] web-based plan 9? Pietro Gagliardi 2008-11-20 14:25 ` Eric Van Hensbergen 2008-11-20 14:37 ` Fco. J. Ballesteros 2008-11-20 14:47 ` Eric Van Hensbergen 2008-11-20 15:07 ` Fco. J. Ballesteros 2008-11-20 15:16 ` Eric Van Hensbergen 2008-11-20 15:21 ` Francisco J Ballesteros 2008-11-20 14:51 ` erik quanstrom 2008-11-20 18:59 ` Skip Tavakkolian 2008-11-20 19:25 ` Skip Tavakkolian 2008-11-20 22:15 ` Giacomo Tesio 2008-11-20 23:18 ` Skip Tavakkolian 2008-11-21 5:19 ` lucio 2008-11-21 10:15 ` Giacomo Tesio 2008-11-21 11:55 ` matt 2008-11-21 14:01 ` Tom Lieber 2008-11-21 14:34 ` matt 2008-11-21 15:13 ` Giacomo Tesio 2008-11-21 15:53 ` matt 2008-11-21 16:05 ` erik quanstrom 2008-11-21 17:05 ` Giacomo Tesio 2008-11-21 17:18 ` erik quanstrom 2008-11-22 20:15 ` Giacomo Tesio 2008-11-21 17:24 ` matt 2008-11-21 18:12 ` a
This is a public inbox, see mirroring instructions for how to clone and mirror all data and code used for this inbox; as well as URLs for NNTP newsgroup(s).