From: Edi Weitz
Subject: Announcement: TBNL
Date: 
Message-ID: <m34qqsx74j.fsf@bird.agharta.de>
Hi!

I've just made an initial release of my little web framework:

  <http://weitz.de/tbnl/>

I'd be interested in bug reports and comments (in case anyone wants to
use it).

Cheers,
Edi.

From: Karl A. Krueger
Subject: Re: Announcement: TBNL
Date: 
Message-ID: <c7hn3k$4bq$1@baldur.whoi.edu>
Edi Weitz <···@agharta.de> wrote:
> I've just made an initial release of my little web framework:
>  <http://weitz.de/tbnl/>
> I'd be interested in bug reports and comments (in case anyone wants to
> use it).

Looks pretty neat.  I've been using html-template in Actual, Real Work
recently -- just report generation, but it's an excuse to learn more
Lisp.  So I'll stuff this somewhere in the middle of my list of things
to learn.

Two bug reports for the Web page above:  First, the section "The TBNL
Dictionary" seems to have some problem with mismatched H4 and H3 tags
which makes it show up strangely in my browser.  Second, "elementy type"
should probably be "element type" in the "Known Quirks".  :)

-- 
Karl A. Krueger <········@example.edu>
Woods Hole Oceanographic Institution
Email address is spamtrapped.  s/example/whoi/
"Outlook not so good." -- Magic 8-Ball Software Reviews
From: Edi Weitz
Subject: Re: Announcement: TBNL
Date: 
Message-ID: <m3r7tvs9zr.fsf@bird.agharta.de>
On Sat, 8 May 2004 04:19:02 +0000 (UTC), "Karl A. Krueger" <········@example.edu> wrote:

> Two bug reports for the Web page above: First, the section "The TBNL
> Dictionary" seems to have some problem with mismatched H4 and H3
> tags which makes it show up strangely in my browser.  Second,
> "elementy type" should probably be "element type" in the "Known
> Quirks".  :)

:)

Thanks, I'll fix that.

Cheers,
Edi.
From: David Steuber
Subject: Re: Announcement: TBNL
Date: 
Message-ID: <87zn8j1nls.fsf@david-steuber.com>
Edi Weitz <···@agharta.de> writes:

> I've just made an initial release of my little web framework:
> 
>   <http://weitz.de/tbnl/>

On the face of it (from the web page), it looks very much like a more
comprehensive version of a web app framework that I am working on.
Now I wonder if I should abandon my effort and just go with this.

I was not going to use kmrcl or cl-modlisp, just the facilities
included with sbcl.  Then I heard about acl-compat.  I haven't decided
to use acl-compat yet because it is a dependency which has a bunch of
other dependencies that adsf-install seems to handle auto-magicly.

You may recall sending me a link to tbnl via e-mail a while back when
I was asking about mod_lisp stuff.  I had already seen cl-modlisp and
two(?) other lisp examples based on modlisp.lisp.

From the page: "TBNL currently can't handle POST requests with the
multipart/form-data (RFC 2388) media type. Specifically, there's no
support for file uploads yet. This will be fixed in a future release."

This is actually one reason I'm not going with cl-modlisp.  I want to
handle all valid requests and also be able to return arbitrary mime
type data.  Your URI dispatch looks like it may be more comprensive
than mine.  I have logic to simply map a string to a function call.
Currently that is handled by a hashtable that is closed over by
several functions that mutex (using sbthred:make-mutex) access.  The
sole purpose of my framework infact is to map requests to function
calls, package the data, and provide some basic utilities for geting
query string and form values.

So not counting my half baked, partially implemented vaporware, there
are now at least two mod_lisp -> lisp web frameworks.  Where's ANSI
with a standard? ;-)

I may just go ahead and complete my framework and steal stuff from
you.  I haven't completely solved how I'm going to package the request
(I was thinking in terms of some sort of CLOS class) and how the
response should be handled.  I want the handler function to be able to
act like an nph script.  I also haven't worked out session handling
other than deciding I was not going to go down the road of URL munging
and just use cookies.

I definitely want to see how closing the socket on a bogus request
works.  That is, if someone crafts a post that sends as much data as
Apache is configured to allow, do you have to read it all in or can
you tell Apache to send back a 404 and close the connection?

-- 
I wouldn't mind the rat race so much if it wasn't for all the damn cats.
From: Edi Weitz
Subject: Re: Announcement: TBNL
Date: 
Message-ID: <m3n04js9om.fsf@bird.agharta.de>
On Sat, 08 May 2004 05:42:25 GMT, David Steuber <·····@david-steuber.com> wrote:

> From the page: "TBNL currently can't handle POST requests with the
> multipart/form-data (RFC 2388) media type. Specifically, there's no
> support for file uploads yet. This will be fixed in a future
> release."
>
> This is actually one reason I'm not going with cl-modlisp.  I want
> to handle all valid requests and also be able to return arbitrary
> mime type data.

Well, you can of course handle all valid requests with mod_lisp. It
just means a bit more work. I haven't done file uploads yet because I
didn't need them up until now.

> The sole purpose of my framework infact is to map requests to
> function calls, package the data, and provide some basic utilities
> for geting query string and form values.

So this is not very different from mine. TBNL is also just a bunch of
convenience functions, basically.

> I definitely want to see how closing the socket on a bogus request
> works.  That is, if someone crafts a post that sends as much data as
> Apache is configured to allow, do you have to read it all in or can
> you tell Apache to send back a 404 and close the connection?

Nope, not with mod_lisp. mod_lisp will read all the data and only then
will you get access to it. This should be built into mod_lisp if you
want it.

Cheers,
Edi.
From: David Steuber
Subject: Re: Announcement: TBNL
Date: 
Message-ID: <87vfj52dk2.fsf@david-steuber.com>
Edi Weitz <···@agharta.de> writes:

> On Sat, 08 May 2004 05:42:25 GMT, David Steuber <·····@david-steuber.com> wrote:
> 
> > From the page: "TBNL currently can't handle POST requests with the
> > multipart/form-data (RFC 2388) media type. Specifically, there's no
> > support for file uploads yet. This will be fixed in a future
> > release."
> >
> > This is actually one reason I'm not going with cl-modlisp.  I want
> > to handle all valid requests and also be able to return arbitrary
> > mime type data.
> 
> Well, you can of course handle all valid requests with mod_lisp. It
> just means a bit more work. I haven't done file uploads yet because I
> didn't need them up until now.

I understand this very well.  In the spirit of lazy code evaluation, I
have fairly recently decided to go with a lazy function implementation
approach.  I don't write functionality until I need it anymore.

> > The sole purpose of my framework infact is to map requests to
> > function calls, package the data, and provide some basic utilities
> > for geting query string and form values.
> 
> So this is not very different from mine. TBNL is also just a bunch of
> convenience functions, basically.

My approach is less flexible.  I root the application in much the same
way that web servers may be configured to put all CGI code in /cgi-bin.
Anything under that is a request to Lisp.  Since there is no directory
mapping underneath the works, if "/foo/bar/baz" is maps to a function,
but "/foo/bar/" does not, a 404 would be returned instead of a 403
denying access to a directory listing or the contents of an index.html
file.  I have no support for the equivalent of asking for "file.ext"
where ext is the extension that Apache would map to a handler.  This
is not to say that it can't be done, just that you would have to go to
some trouble to register the handler on the lisp side.

> > I definitely want to see how closing the socket on a bogus request
> > works.  That is, if someone crafts a post that sends as much data as
> > Apache is configured to allow, do you have to read it all in or can
> > you tell Apache to send back a 404 and close the connection?
> 
> Nope, not with mod_lisp. mod_lisp will read all the data and only then
> will you get access to it. This should be built into mod_lisp if you
> want it.

I've not built Apache modules.  Even though mod_lisp.c is clearly a
simple derivative of the example file, Apache has a new API for 2.x.
I don't want to go to the effort of learning 2.x at this point.

The functionality is mainly useful for dealing with a DOS attack.  At
least that is what I want it for.  It is not a strong want though.
Also such protection may not be very effective.

I am currently leaning towards finishing my framework and then
comparing it to TBNL and cl-modlisp.  If I'm not completely ashamed of
my code, I will share it as you and KMR have with your respective
packages.  There are other Lisp side mod_lisp codes out there.  I
don't see that adding one more would hurt.  Also, you and KMR have
taken the trouble to write portable code.  I can just go ahead and be
SBCL with (list :sb-thread :sb-futex) enabled specific.

The main benefit I would get from finishing and releasing my code
would be the learning experience and whatever feedback I get from more
experienced lispers.

Thanks for releasing TBNL.

-- 
I wouldn't mind the rat race so much if it wasn't for all the damn cats.