[9fans] web-based plan 9?

[9fans] web-based plan 9?

[Pietro Gagliardi]

-----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-----

Re: [9fans] web-based plan 9?

[Eric Van Hensbergen]

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

Re: [9fans] web-based plan 9?

[Fco. J. Ballesteros]

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

Re: [9fans] web-based plan 9?

[Eric Van Hensbergen]

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

Re: [9fans] web-based plan 9?

[Fco. J. Ballesteros]

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

Re: [9fans] web-based plan 9?

[Eric Van Hensbergen]

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

Re: [9fans] web-based plan 9?

[Francisco J Ballesteros]

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
>
>

Re: [9fans] web-based plan 9?

[erik quanstrom]

> 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

Re: [9fans] web-based plan 9?

[Skip Tavakkolian]

> 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.

Re: [9fans] web-based plan 9?

[Skip Tavakkolian]

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.

Re: [9fans] web-based plan 9?

[Giacomo Tesio]

[-- 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 --]

Re: [9fans] web-based plan 9?

[Skip Tavakkolian]

>    - 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

Re: [9fans] web-based plan 9?

[lucio]

> 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?

Re: [9fans] web-based plan 9?

[Giacomo Tesio]

[-- 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 --]

Re: [9fans] web-based plan 9?

[matt]

>
> 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.

Re: [9fans] web-based plan 9?

[Tom Lieber]

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/

Re: [9fans] web-based plan 9?

[matt]

>> 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.

Re: [9fans] web-based plan 9?

[Giacomo Tesio]

[-- 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 --]

Re: [9fans] web-based plan 9?

[matt]

 > 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>

Re: [9fans] web-based plan 9?

[erik quanstrom]

> 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

Re: [9fans] web-based plan 9?

[Giacomo Tesio]

[-- 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 --]

Re: [9fans] web-based plan 9?

[erik quanstrom]

>    - 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

Re: [9fans] web-based plan 9?

[Giacomo Tesio]

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

Re: [9fans] web-based plan 9?

[matt]

>
> 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,

Re: [9fans] web-based plan 9?

[a]

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.