Re: [9fans] Web Server

Re: [9fans] Web Server

[forsyth]

[-- Attachment #1: Type: text/plain, Size: 180 bytes --]

ip/httpd/httpd; see http(8) in the manual;
the system comes configured to invoke it via aux/listen
using /bin/service/tcp80.  just cat that file to see
how it is configured.


[-- Attachment #2: Type: message/rfc822, Size: 1917 bytes --]

To: cse.psu.edu!9fans
Subject: [9fans] Web Server
Date: Mon, 18 Dec 2000 10:02:21 GMT
Message-ID: <91giih$d1h$1@nnrp1.deja.com>

Hi,

I'm considering installing Plan 9 and was wondering if it comes with a
web server, if so, what is its name?

Thanks


Sent via Deja.com
http://www.deja.com/

[9fans] web server

[Rudolf Sykora]

Hello,

I've been wondering (and not reading much)...
If I'd like to use plan9 as a www server, is there anything ready?
How difficult would it be to use rails or merb in plan9? Is it feasible?

thanks
ruda

Re: [9fans] web server

[erik quanstrom]

yes.  there are several web servers, including one in the standard
dist.  however, rails or merb might be something you'd have to do
yourself.

- erik

Re: [9fans] web server

[Enrico Weigelt]

* erik quanstrom <quanstro@quanstro.net> wrote:

Hi,

> yes.  there are several web servers, including one in the standard
> dist.  however, rails or merb might be something you'd have to do
> yourself.

Did anyone already get java running on Plan9 ?
I dont know anything about ruby, but IMHO python could be compiled
into java bytecode, perl & php could at least be partially compiled
and partially emulated.

Maybe it would be a wise to go that way.


cu
--
----------------------------------------------------------------------
 Enrico Weigelt, metux IT service -- http://www.metux.de/

 cellphone: +49 174 7066481   email: info@metux.de   skype: nekrad666
----------------------------------------------------------------------
 Embedded-Linux / Portierung / Opensource-QM / Verteilte Systeme
----------------------------------------------------------------------

Re: [9fans] web server

[Roman V. Shaposhnik]

On Sat, 2009-04-18 at 19:19 +0200, Enrico Weigelt wrote:
> > yes.  there are several web servers, including one in the standard
> > dist.  however, rails or merb might be something you'd have to do
> > yourself.
>
> Did anyone already get java running on Plan9 ?

Java is too many things. Strictly speaking, a sane implementation
of JVM running natively on Plan9 could be a good thing. I'm not
sure whether Sun's JVM would be a managable thing to port, but
long time ago in another life I've seen a really good attempt
at [re]implementing JVM by some guys from Finland. Not sure the
project is still alive though.

Thanks,
Roman.

Re: [9fans] web server

[Devon H. O'Dell]

2009/4/16 Rudolf Sykora <rudolf.sykora@gmail.com>:
> Hello,
>
> I've been wondering (and not reading much)...
> If I'd like to use plan9 as a www server, is there anything ready?

Yes, there is a pre-built httpd and libraries for writing your own.
Recent apache probably doesn't compile in APE (but maybe it does).

> How difficult would it be to use rails or merb in plan9? Is it feasible?

Very difficult. No, not feasible. You would have to port Ruby. And
then possibly rails, too. Plan 9 isn't UNIX, or UNIX-like, or POSIX
(or POSIX-like). APE helps with some stuff, but not all the way.

> thanks
> ruda

--dho

Re: [9fans] web server

[Rudolf Sykora]

>
>> How difficult would it be to use rails or merb in plan9? Is it feasible?
>
> Very difficult. No, not feasible. You would have to port Ruby. And
> then possibly rails, too. Plan 9 isn't UNIX, or UNIX-like, or POSIX
> (or POSIX-like). APE helps with some stuff, but not all the way.

I thought I'd seen a ruby port in the contrib list...
And if merb were just written (portably) in ruby, then, I thought, it
wouldn't have to be that difficult...

ruda

Re: [9fans] web server

[erik quanstrom]

> I thought I'd seen a ruby port in the contrib list...
> And if merb were just written (portably) in ruby, then, I thought, it
> wouldn't have to be that difficult...

/n/sources/contrib/fgb/tar/ruby.tgz

- erik

Re: [9fans] web server

[maht]

>>> How difficult would it be to use rails or merb in plan9? Is it feasible?
Not Rails or merb or anything non Plan 9 but a few of us are building an
rc shell based system that works anywhere CGI and Plan 9 / plan9port is
available.

http://werc.cat-v.org/

Re: [9fans] web server

[Rudolf Sykora]

2009/4/17 maht <mattmobile@proweb.co.uk>:
>
>>>> How difficult would it be to use rails or merb in plan9? Is it feasible?
>
> Not Rails or merb or anything non Plan 9 but a few of us are building an rc
> shell based system that works anywhere CGI and Plan 9 / plan9port is
> available.
>
> http://werc.cat-v.org/

Yes, I've noticed the existence of werc. I'll take a look at that, sure.
However, I have just discovered 'seaside' web framework and am looking
at it now. It seems to be pretty interesting. Based on smalltalk and
using a different (and to me appealing) philosophy, other than MCV.

Thanks
ruda

Re: [9fans] web server

[Roman V. Shaposhnik]

On Fri, 2009-04-17 at 12:54 +0100, maht wrote:
> >>> How difficult would it be to use rails or merb in plan9? Is it feasible?
> Not Rails or merb or anything non Plan 9 but a few of us are building an
> rc shell based system that works anywhere CGI and Plan 9 / plan9port is
> available.
>
> http://werc.cat-v.org/

I was not aware of werc. Is there a good doc for it?

Thanks,
Roman.

P.S. So far it seems that werc wouldn't be able to manage
highly dynamic and volatile URI hierarchies as long as it
is run under anything  but Plan9. Ironically it doesn't
seem to run there.

Re: [9fans] web server

[Uriel]

On Sun, Apr 26, 2009 at 11:59 PM, Roman V. Shaposhnik <rvs@sun.com> wrote:
> On Fri, 2009-04-17 at 12:54 +0100, maht wrote:
>> >>> How difficult would it be to use rails or merb in plan9? Is it feasible?
>> Not Rails or merb or anything non Plan 9 but a few of us are building an
>> rc shell based system that works anywhere CGI and Plan 9 / plan9port is
>> available.
>>
>> http://werc.cat-v.org/
>
> I was not aware of werc. Is there a good doc for it?

Besides http://werc.cat-v.org/docs/ the included README and the source
should be helpful (there is not much code there, and should be mostly
self-documenting).

>
> Thanks,
> Roman.
>
> P.S. So far it seems that werc wouldn't be able to manage
> highly dynamic and volatile URI hierarchies as long as it

Actually it does, for example all the URLs in http://man.cat-v.org are
'synthetically' generated on the fly.

> is run under anything  but Plan9. Ironically it doesn't
> seem to run there.

It does run under any CGI environment, there are various ways to
provide a CGI environment in Plan 9.

uriel

Re: [9fans] web server

[maht]

>
> P.S. So far it seems that werc wouldn't be able to manage
> highly dynamic and volatile URI hierarchies as long as it
> is run under anything  but Plan9. Ironically it doesn't
> seem to run there.
>
>
I use ~ patterns for URI matching on my site

http://ten.steponnopets.net/

it's a bit of a work in progress to exercise the various elements I'm
working with for a bigger project

http://ten.steponnopets.net/Source_code_for_this

Re: [9fans] web server

[erik quanstrom]

> I use ~ patterns for URI matching on my site

what are "~ patterns"?

- erik

Re: [9fans] web server

[maht]

erik quanstrom wrote:
>> I use ~ patterns for URI matching on my site
>>
>
> what are "~ patterns"?
>
rc shell pattern matching

Re: [9fans] web server

[Uriel]

>> How difficult would it be to use rails or merb in plan9? Is it feasible?
>
> Very difficult. No, not feasible. You would have to port Ruby. And
> then possibly rails, too. Plan 9 isn't UNIX, or UNIX-like, or POSIX
> (or POSIX-like). APE helps with some stuff, but not all the way.

And then you would need some hideous SQL database.

As ken said: we have persistent objects, they are called files; and
that is what werc uses.

Writing the core of a blog engine in three lines of rc is hard to
beat, plus you get the benefit of being able to manipulate and manage
all your data using the tools any self respecting Unix user loves.

uriel

Re: [9fans] web server

[Rudolf Sykora]

> Writing the core of a blog engine in three lines of rc is hard to
> beat, plus you get the benefit of being able to manipulate and manage
> all your data using the tools any self respecting Unix user loves.
>
> uriel

well, I haven't thought about it deeply yet, but what I guess could be
a problem with your approach is that many features would have to be
somehow implemented first so that it all be useable. I mean e.g. ajax
style of page content refresh, session management, perhaps POST method
too.

ruda

Re: [9fans] web server

[Devon H. O'Dell]

2009/4/17 Rudolf Sykora <rudolf.sykora@gmail.com>:
>> Writing the core of a blog engine in three lines of rc is hard to
>> beat, plus you get the benefit of being able to manipulate and manage
>> all your data using the tools any self respecting Unix user loves.
>>
>> uriel
>
> well, I haven't thought about it deeply yet, but what I guess could be
> a problem with your approach is that many features would have to be
> somehow implemented first so that it all be useable. I mean e.g. ajax
> style of page content refresh, session management, perhaps POST method
> too.

Not really. There's nothing magical about AJAX. It's just HTTP
requests. As long as you support those, your pages can use AJAX.

--dho

> ruda
>
>

Re: [9fans] web server

[maht]

> well, I haven't thought about it deeply yet, but what I guess could be
> a problem with your approach is that many features would have to be
> somehow implemented first so that it all be useable. I mean e.g. ajax
> style of page content refresh, session management, perhaps POST method
> too.
>
> ruda
>
>
>

never say it is impossible to man busy doing it

Re: [9fans] web server

[Rudolf Sykora]

2009/4/17 maht <mattmobile@proweb.co.uk>:
>
>> well, I haven't thought about it deeply yet, but what I guess could be
>> a problem with your approach is that many features would have to be
>> somehow implemented first so that it all be useable. I mean e.g. ajax
>> style of page content refresh, session management, perhaps POST method
>> too.
>>
>> ruda
>>
>
> never say it is impossible to man busy doing it

have I ?
r

Re: [9fans] web server

[Uriel]

On Fri, Apr 17, 2009 at 2:45 PM, Rudolf Sykora <rudolf.sykora@gmail.com> wrote:
>> Writing the core of a blog engine in three lines of rc is hard to
>> beat, plus you get the benefit of being able to manipulate and manage
>> all your data using the tools any self respecting Unix user loves.
>>
>> uriel
>
> well, I haven't thought about it deeply yet, but what I guess could be
> a problem with your approach is that many features would have to be
> somehow implemented first so that it all be useable. I mean e.g. ajax
> style of page content refresh, session management, perhaps POST method
> too.

Whatever AJAX and sessions are good web development practices is
questionable, but in any case werc does provides you with the tools to
implement such things if that is what you really want.

Werc handles POST just fine, and actually maht just implemented
multiple file upload, which I never bothered to do because I never had
use for it and thought it would be too hard, apparently didn't take
him more than an afternoon to do it.

uriel

Re: [9fans] web server

[john]

> On Fri, Apr 17, 2009 at 2:45 PM, Rudolf Sykora <rudolf.sykora@gmail.com> wrote:
>>> Writing the core of a blog engine in three lines of rc is hard to
>>> beat, plus you get the benefit of being able to manipulate and manage
>>> all your data using the tools any self respecting Unix user loves.
>>>
>>> uriel
>>
>> well, I haven't thought about it deeply yet, but what I guess could be
>> a problem with your approach is that many features would have to be
>> somehow implemented first so that it all be useable. I mean e.g. ajax
>> style of page content refresh, session management, perhaps POST method
>> too.
>
> Whatever AJAX and sessions are good web development practices is
> questionable, but in any case werc does provides you with the tools to
> implement such things if that is what you really want.
>
> Werc handles POST just fine, and actually maht just implemented
> multiple file upload, which I never bothered to do because I never had
> use for it and thought it would be too hard, apparently didn't take
> him more than an afternoon to do it.
>
> uriel

So, how hard is it to get werc running on real Plan 9? The readme was
for Plan 9 Ports last time I checked.


John

Re: [9fans] web server

[Uriel]

> So, how hard is it to get werc running on real Plan 9? The readme was
> for Plan 9 Ports last time I checked.

Shouldn't be hard, aside from a couple of paths that might need fixing
(perhaps using bind(1) will do), it should run out of the box.

The only issue is that it expects to run as a CGI, so you will need to
either use pegasus or some adapter for the standard httpd, there is a
fancy one in russ' contrib dir, but a shell script that sets the two
or three CGI vars werc uses should probably be enough, and I think
somebody did just that.

Hopefully somebody will write a more detailed howto, patches and docs welcome ;)

Peace

uriel

Re: [9fans] web server

[john]

>> So, how hard is it to get werc running on real Plan 9? The readme was
>> for Plan 9 Ports last time I checked.
>
> Shouldn't be hard, aside from a couple of paths that might need fixing
> (perhaps using bind(1) will do), it should run out of the box.
>
> The only issue is that it expects to run as a CGI, so you will need to
> either use pegasus or some adapter for the standard httpd, there is a
> fancy one in russ' contrib dir, but a shell script that sets the two
> or three CGI vars werc uses should probably be enough, and I think
> somebody did just that.
>
> Hopefully somebody will write a more detailed howto, patches and docs welcome ;)
>
> Peace
>
> uriel

Ok, so I'm probably being really dumb here, but I'm trying to get CGI
to work and not quite sure what I need to do.

I stuck cgi.c in the httpd source directory, compiled and installed; now
I have /bin/ip/httpd/cgi. I created /bin/ip/httpd/cgi-bin and stuck a
rc script ("foo") in there that says "Hello world". Now, from my probably flawed
reading of the cgi source, I thought I'd just do:
http://myserver/magic/cgi/foo
to run my script 'foo'.  However...  nothing.  Don't even get an
error, just a blank page.  Am I missing something?  This intersects a
few areas that I don't know much about--the Plan 9 httpd server, and
how cgi stuff works in general.


John Floren

Re: [9fans] web server

[Steve Simon]

> http://myserver/magic/cgi/foo

check the logfile /sys/log/httpd/clf

also, don't you want to do somthing more like:

	http://myserver/magic/cgi/foo?var1=val1?var2=val2

This is an educated guess rather tha experience talking.

-Steve

Re: [9fans] web server

[erik quanstrom]

> 	http://myserver/magic/cgi/foo?var1=val1?var2=val2

i think you wish

	http://myserver/magic/cgi?var1=val1&var2=val2

- erik

Re: [9fans] web server

[john]

>> 	http://myserver/magic/cgi/foo?var1=val1?var2=val2
>
> i think you wish
>
> 	http://myserver/magic/cgi?var1=val1&var2=val2
>
> - erik

So what are these magical vars? Where do I specify
the cgi program to run?


John

Re: [9fans] web server

[erik quanstrom]

On Sun Apr 19 09:13:28 EDT 2009, john@csplan9.rit.edu wrote:
> >> 	http://myserver/magic/cgi/foo?var1=val1?var2=val2
> >
> > i think you wish
> >
> > 	http://myserver/magic/cgi?var1=val1&var2=val2
> >
> > - erik
>
> So what are these magical vars? Where do I specify
> the cgi program to run?

"cgi" is a standin for the name of the program you
wish to run from the webserver.  the variables depend
on the program run.  webls is a good starting point.

- erik

Re: [9fans] web server

[Skip Tavakkolian]

you could make local mods to your httpd so that paths starting with
/cgi are given similar treatment as those that start with /magic; it
would execute "cgi" and pass it the arguments as usual.  then url is:

http://myserver/cgi/foo?var1=1&var2=2

and in script "foo" the $QUERY_STRING will be "var1=1&var2=2"

>>> 	http://myserver/magic/cgi/foo?var1=val1?var2=val2
>>
>> i think you wish
>>
>> 	http://myserver/magic/cgi?var1=val1&var2=val2
>>
>> - erik
>
> So what are these magical vars? Where do I specify
> the cgi program to run?
>
>
> John

Re: [9fans] web server

[erik quanstrom]

On Sun Apr 19 12:03:54 EDT 2009, 9nut@9netics.com wrote:
> you could make local mods to your httpd so that paths starting with
> /cgi are given similar treatment as those that start with /magic; it
> would execute "cgi" and pass it the arguments as usual.  then url is:
>
> http://myserver/cgi/foo?var1=1&var2=2
>
> and in script "foo" the $QUERY_STRING will be "var1=1&var2=2"

if you look at /sys/src/cmd/ip/httpd/init.c you'll see that
argv[3] is the query string.

minooka; g req.search init.c
init.c:97: 	connect.req.search = argv[3];

there has been some recent reorganization of httpd.c
that i haven't carefully looked at.

about the same time i made a few modifications of my
own to eliminate some bad interactions between magic,
@ and other redirections.  i don't recall the senerio
exactly, but depending on the situation, arguments
could be parsed or not parsed.

if anyone else needs that, i'd be glad to put it on sources.

- erik

Re: [9fans] web server

[Federico G. Benavento]

skip is pretty much on the point exactly the same convention is valid
for cgifs.

http://machine/cgifs/script?var0=val0&var1=val1

cgi as cgifs are programs that parse the requested uri and from there,
after the 2nd '/', get the script name "script" in the example above.

On Sun, Apr 19, 2009 at 2:05 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> On Sun Apr 19 12:03:54 EDT 2009, 9nut@9netics.com wrote:
>> you could make local mods to your httpd so that paths starting with
>> /cgi are given similar treatment as those that start with /magic; it
>> would execute "cgi" and pass it the arguments as usual.  then url is:
>>
>> http://myserver/cgi/foo?var1=1&var2=2
>>
>> and in script "foo" the $QUERY_STRING will be "var1=1&var2=2"
>
> if you look at /sys/src/cmd/ip/httpd/init.c you'll see that
> argv[3] is the query string.
>
> minooka; g req.search init.c
> init.c:97:      connect.req.search = argv[3];
>
> there has been some recent reorganization of httpd.c
> that i haven't carefully looked at.
>
> about the same time i made a few modifications of my
> own to eliminate some bad interactions between magic,
> @ and other redirections.  i don't recall the senerio
> exactly, but depending on the situation, arguments
> could be parsed or not parsed.
>
> if anyone else needs that, i'd be glad to put it on sources.
>
> - erik
>
>



-- 
Federico G. Benavento

Re: [9fans] web server

[erik quanstrom]

On Sun Apr 19 18:04:51 EDT 2009, benavento@gmail.com wrote:
> skip is pretty much on the point exactly the same convention is valid
> for cgifs.
>
> http://machine/cgifs/script?var0=val0&var1=val1
>
> cgi as cgifs are programs that parse the requested uri and from there,
> after the 2nd '/', get the script name "script" in the example above.
>
> On Sun, Apr 19, 2009 at 2:05 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> > On Sun Apr 19 12:03:54 EDT 2009, 9nut@9netics.com wrote:
> >> you could make local mods to your httpd so that paths starting with
> >> /cgi are given similar treatment as those that start with /magic; it
> >> would execute "cgi" and pass it the arguments as usual.  then url is:
> >>
> >> http://myserver/cgi/foo?var1=1&var2=2
> >>
> >> and in script "foo" the $QUERY_STRING will be "var1=1&var2=2"
> >
> > if you look at /sys/src/cmd/ip/httpd/init.c you'll see that
> > argv[3] is the query string.
> >

minooka; cd /n/sources/plan9/sys/src
minooka; grep QUERY_STRING libhttpd/* cmd/ip/httpd/*
minooka; strings /386/bin/ip/httpd/* | grep QUERY_STRING

yields nothing.  maybe this is true for something else, but it's not
true of the distributed httpd.

- erik

Re: [9fans] web server

[Federico G. Benavento]

again cgi is a standalone app, /n/sources/contrib/rsc/cgi.c is the one
setting QUERY_STRING

On Sun, Apr 19, 2009 at 8:21 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> On Sun Apr 19 18:04:51 EDT 2009, benavento@gmail.com wrote:
>> skip is pretty much on the point exactly the same convention is valid
>> for cgifs.
>>
>> http://machine/cgifs/script?var0=val0&var1=val1
>>
>> cgi as cgifs are programs that parse the requested uri and from there,
>> after the 2nd '/', get the script name "script" in the example above.
>>
>> On Sun, Apr 19, 2009 at 2:05 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> > On Sun Apr 19 12:03:54 EDT 2009, 9nut@9netics.com wrote:
>> >> you could make local mods to your httpd so that paths starting with
>> >> /cgi are given similar treatment as those that start with /magic; it
>> >> would execute "cgi" and pass it the arguments as usual.  then url is:
>> >>
>> >> http://myserver/cgi/foo?var1=1&var2=2
>> >>
>> >> and in script "foo" the $QUERY_STRING will be "var1=1&var2=2"
>> >
>> > if you look at /sys/src/cmd/ip/httpd/init.c you'll see that
>> > argv[3] is the query string.
>> >
>
> minooka; cd /n/sources/plan9/sys/src
> minooka; grep QUERY_STRING libhttpd/* cmd/ip/httpd/*
> minooka; strings /386/bin/ip/httpd/* | grep QUERY_STRING
>
> yields nothing.  maybe this is true for something else, but it's not
> true of the distributed httpd.
>
> - erik
>
>



-- 
Federico G. Benavento

Re: [9fans] web server

[Skip Tavakkolian]

i think John mentioned he was using cgi.c that's in Russ' contrib
area.  did i imagine it?  (entirely possible)

> On Sun Apr 19 18:04:51 EDT 2009, benavento@gmail.com wrote:
>> skip is pretty much on the point exactly the same convention is valid
>> for cgifs.
>>
>> http://machine/cgifs/script?var0=val0&var1=val1
>>
>> cgi as cgifs are programs that parse the requested uri and from there,
>> after the 2nd '/', get the script name "script" in the example above.
>>
>> On Sun, Apr 19, 2009 at 2:05 PM, erik quanstrom <quanstro@quanstro.net> wrote:
>> > On Sun Apr 19 12:03:54 EDT 2009, 9nut@9netics.com wrote:
>> >> you could make local mods to your httpd so that paths starting with
>> >> /cgi are given similar treatment as those that start with /magic; it
>> >> would execute "cgi" and pass it the arguments as usual.  then url is:
>> >>
>> >> http://myserver/cgi/foo?var1=1&var2=2
>> >>
>> >> and in script "foo" the $QUERY_STRING will be "var1=1&var2=2"
>> >
>> > if you look at /sys/src/cmd/ip/httpd/init.c you'll see that
>> > argv[3] is the query string.
>> >
>
> minooka; cd /n/sources/plan9/sys/src
> minooka; grep QUERY_STRING libhttpd/* cmd/ip/httpd/*
> minooka; strings /386/bin/ip/httpd/* | grep QUERY_STRING
>
> yields nothing.  maybe this is true for something else, but it's not
> true of the distributed httpd.
>
> - erik

Re: [9fans] web server

[erik quanstrom]

On Sun Apr 19 21:44:25 EDT 2009, 9nut@9netics.com wrote:
> i think John mentioned he was using cgi.c that's in Russ' contrib
> area.  did i imagine it?  (entirely possible)

i'm sorry.  i took "cgi" to be a free variable.  my mistake.

- erik

Re: [9fans] web server

[maht]

cgi is more than parsing query strings, there are at least two other
variable passing mechanisms x-www-form-encoded (query string as the POST
body) and multipart/form-data - the sort that's required when uploading
binary stuff.


Common Gateway Interface is a 36 page RFC : http://www.ietf.org/rfc/rfc3875

My form upload decoder is here if anyone is interested
http://www.proweb.co.uk/~matt/werc/cgilib.rc:35

Re: [9fans] web server

[erik quanstrom]

On Fri Apr 17 08:33:12 EDT 2009, uriel99@gmail.com wrote:
> And then you would need some hideous SQL database.
>
> As ken said: we have persistent objects, they are called files; and
> that is what werc uses.

i feel compelled to defend one of my favorite quotes
of all time from misapplication.  i'm sure that werc is
well-engineered for its domain, but the mistake i see
is generalizing this into sql sucks.

just as a point of pedantry, in a standard sql database,
there are no objects.

sql does not suck.  here's why.  sql databases are really
good at keeping relationships between rows (here's the
important part) with no locking visible to the client.
even better in the face of non-static requirements,
more relationships can be added on the fly.  it's hard
to do this with flat files, and file-based locking (like
upas does for mbox files) is pretty tricky.

- erik

Re: [9fans] web server

[Uriel]

While I think SQL  *really* sucks (besides smelling too much of COBOL,
it pretends to be relational when it is not), that was not my point,
and I agree with you that relational databases don't store objects,
and that relational databases do have valid uses that are sadly often
overlooked (maybe this wouldn't be the case if they didn't keep adding
'features' to store XML 'objects' in them and other such
abominations).

My criticism was directed at how they are actually used in pretty much
every web 'framework' under the sun: with some hideously messy ORM
layer, they plug round Objects down the square db tables, and all of
it to write applications which really are representing files (accessed
over HTTP).

It is not uncommon to see people modeling with Objects file
hierarchies that then they go and store into a relational database.

So by using files to store and model data not only avoids having to
map a fs-like interface to a table oriented one, but the object
oriented convolution in between.

And that is short is what allows you to write a blog engine in three
lines of rc, because rc and the rest of the toolkit that comes with it
are designed to work on and with files and file paths.

uriel

On Fri, Apr 17, 2009 at 3:22 PM, erik quanstrom <quanstro@quanstro.net> wrote:
> On Fri Apr 17 08:33:12 EDT 2009, uriel99@gmail.com wrote:
>> And then you would need some hideous SQL database.
>>
>> As ken said: we have persistent objects, they are called files; and
>> that is what werc uses.
>
> i feel compelled to defend one of my favorite quotes
> of all time from misapplication.  i'm sure that werc is
> well-engineered for its domain, but the mistake i see
> is generalizing this into sql sucks.
>
> just as a point of pedantry, in a standard sql database,
> there are no objects.
>
> sql does not suck.  here's why.  sql databases are really
> good at keeping relationships between rows (here's the
> important part) with no locking visible to the client.
> even better in the face of non-static requirements,
> more relationships can be added on the fly.  it's hard
> to do this with flat files, and file-based locking (like
> upas does for mbox files) is pretty tricky.
>
> - erik
>
>

Re: [9fans] web server

[erik quanstrom]

> While I think SQL  *really* sucks (besides smelling too much of COBOL,
> it pretends to be relational when it is not),

your facts here are incorrect.  clearly sql is relational, if you take
codd's meaning of the term.  also sql as a language has nothing
to do with cobol.  cobol, like fortran, c, java and limbo are
all imperitive languges.  sql is interesting (and powerful) because
it is declarative.  you don't tell the database how to do something
you tell it what to do.

> My criticism was directed at how they are actually used in pretty much
> every web 'framework' under the sun: with some hideously messy ORM
..
> It is not uncommon to see people modeling with Objects file
> hierarchies that then they go and store into a relational database.

i agree with this.  but that doesn't make sql or relational databases
bad, or even bad for this job.  just misued.

- erik

Re: [9fans] web server

[Uriel]

On Sun, Apr 19, 2009 at 12:27 AM, erik quanstrom <quanstro@quanstro.net> wrote:
>> While I think SQL  *really* sucks (besides smelling too much of COBOL,
>> it pretends to be relational when it is not),
>
> your facts here are incorrect.  clearly sql is relational, if you take
> codd's meaning of the term.  also sql as a language has nothing
> to do with cobol.  cobol, like fortran, c, java and limbo are
> all imperitive languges.  sql is interesting (and powerful) because
> it is declarative.  you don't tell the database how to do something
> you tell it what to do.

I really didn't want to get into this debate, my point about COBOL was
more about the archaic syntax than anything else.

As for SQL being relational, C.J. Date and other relational database
people beg to differ, but again, it is not something I'm interested in
arguing about (and is perhaps a mostly academic argument anyway,
although the shortcomings of pretty much all SQL implementations are
all too real), but for more info I would recommend
http://www.thethirdmanifesto.com/ and http://www.dbdebunk.com

I used to really hate relational databases, until I found out that
what I had been using all along were really aberrations of the real
idea, which is quite neat and interesting. Sort of similar to the
process of going from various (l)unixes to Plan 9.

Peace

uriel

Re: [9fans] web server

[erik quanstrom]

> I really didn't want to get into this debate, my point about COBOL was
> more about the archaic syntax than anything else.

the way not to get into a debate is to not make controvertial
claims about the facts.

- erik

Re: [9fans] web server

[Roman V. Shaposhnik]

On Sun, 2009-04-19 at 00:13 +0200, Uriel wrote:
> My criticism was directed at how they are actually used in pretty much
> every web 'framework' under the sun: with some hideously messy ORM
> layer, they plug round Objects down the square db tables, and all of
> it to write applications which really are representing files (accessed
> over HTTP).

I'd say that the biggest reason for DB overuse by Web folks is the
fact that this is how they get persistence for their data while
still being able to build distributed applications.

In general, there are only two ways of having persistent data:
   * DBs
   * FSs
(well, ok, there's third these days)

FSs (under most OSes) have been way to clunky in the presence
of any kind of distribution. Hence the DBs.

> So by using files to store and model data not only avoids having to
> map a fs-like interface to a table oriented one, but the object
> oriented convolution in between.
>
> And that is short is what allows you to write a blog engine in three
> lines of rc, because rc and the rest of the toolkit that comes with it
> are designed to work on and with files and file paths.

FSs have a bit of a downside in how they make everything look like
tree structures. This is not that big of a deal when you can have
truly dynamic trees, but I still haven't seen how werc takes care
of that.

Thanks,
Roman.

Re: [9fans] web server

[hiro]

>FSs have a bit of a downside in how they make everything look like tree structures.

In which way is this a constrain?

Re: [9fans] web server

[erik quanstrom]

> On Sun, 2009-04-19 at 00:13 +0200, Uriel wrote:
> > My criticism was directed at how they are actually used in pretty much
> > every web 'framework' under the sun: with some hideously messy ORM
> > layer, they plug round Objects down the square db tables, and all of
> > it to write applications which really are representing files (accessed
> > over HTTP).
>
> I'd say that the biggest reason for DB overuse by Web folks is the
> fact that this is how they get persistence for their data while
> still being able to build distributed applications.
>
> In general, there are only two ways of having persistent data:
>    * DBs
>    * FSs
> (well, ok, there's third these days)
>
> FSs (under most OSes) have been way to clunky in the presence
> of any kind of distribution. Hence the DBs.

i agree that this is the general line of thinking, but i think option #3
is missing.  there's lots of ephemerial data that doesn't make sense
to keep in a database even if you have one.  if you do cc processing, some of it may
be unwise to let the cgi see or illegal to store in a database (example:
the verification code from the back of a credit card).  so i always thought
it made sense to have a session server to deal with these problems.
we kept the connection information fit to keep in the filesystem.  that
was pretty easy.

- erik

[9fans] Web Server

[thedesertfox95]

Hi,

I'm considering installing Plan 9 and was wondering if it comes with a
web server, if so, what is its name?

Thanks


Sent via Deja.com
http://www.deja.com/