From edi at agharta.de  Mon Apr  7 04:07:44 2008
From: edi at agharta.de (Edi Weitz)
Date: Mon, 07 Apr 2008 06:07:44 +0200
Subject: [hunchentoot-devel] using SESSION-VALUE without START-SESSION
	will never call HT::COUNT-SESSION-USAGE
In-Reply-To: <loom.20080329T234055-295@post.gmane.org> (Lars Rune
	=?iso-8859-1?q?N=F8stdal's?= message of "Sat,
	29 Mar 2008 23:55:53 +0000 (UTC)")
References: <loom.20080329T234055-295@post.gmane.org>
Message-ID: <u7ifaqpdb.fsf@agharta.de>

On Sat, 29 Mar 2008 23:55:53 +0000 (UTC), Lars Rune N?stdal <larsnostdal at gmail.com> wrote:

> from the documentation (which is great btw.) I assumed "(counting
> only requests which use sessions)" included cases where I used
> SESSION-VALUE since, well, i "use" sessions then ... :)

Well, kind of.  The documentation says that sessions have to be
started explicitly with START-SESSION or implictly with (SETF
SESSION-VALUE).  One could argue that pages which use neither of these
operations don't really /use/ sessions as you can't be sure that
you're in a session in that case.

Anyway, what is the actualy problem you're trying to solve?  The
current situation is that there's only a check for a session GC if a
new session /might/ be created.  One could even improve this by only
checking for a session GC if a new session /is/ actually created.  If
your code actually relies on /counting/ something, you should probably
implement your own counter for this, shouldn't you?


From edi at agharta.de  Tue Apr  8 14:44:52 2008
From: edi at agharta.de (Edi Weitz)
Date: Tue, 08 Apr 2008 16:44:52 +0200
Subject: [hunchentoot-devel] New release 0.15.5
Message-ID: <ud4p0iexn.fsf@agharta.de>

Version 0.15.5
2008-04-08
Removed FORCE-OUTPUT* and thus the ACL-COMPAT dependency (thanks to Hans H?bner)
Support for MP-less CMUCL (thanks to Hans H?bner)


From edi at agharta.de  Wed Apr  9 08:19:25 2008
From: edi at agharta.de (Edi Weitz)
Date: Wed, 09 Apr 2008 10:19:25 +0200
Subject: [hunchentoot-devel] New release 0.15.6
Message-ID: <uskxvsanm.fsf@agharta.de>

Version 0.15.6
2008-04-09
Fixed embarrassingly mis-placed parentheses (thanks to Hans H?bner)


From hans at huebner.org  Wed Apr  9 09:39:54 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Wed, 9 Apr 2008 11:39:54 +0200
Subject: [hunchentoot-devel] mod_lisp anyone?
Message-ID: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>

Hi,

I'm planning to make some substantial changes to Hunchentoot and it
would be helpful if I could remove mod_lisp support in this process.

If you are using Hunchentoot with mod_lisp, please let us know.

Thanks,
Hans


From alemmens at xs4all.nl  Wed Apr  9 09:43:53 2008
From: alemmens at xs4all.nl (Arthur Lemmens)
Date: Wed, 09 Apr 2008 11:43:53 +0200
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
Message-ID: <op.t9b7zf05wpmq96@smtp.xs4all.nl>

Hans H?bner wrote:

> If you are using Hunchentoot with mod_lisp, please let us know.

I'm not using it yet, but a client of mine intends to start using
this combination in the future.  So if it isn't too much trouble
to keep the mod_lisp support, I'd appreciate it.

Thanks,

Arthur



From edi at agharta.de  Wed Apr  9 09:56:46 2008
From: edi at agharta.de (Edi Weitz)
Date: Wed, 09 Apr 2008 11:56:46 +0200
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <op.t9b7zf05wpmq96@smtp.xs4all.nl> (Arthur Lemmens's message of
	"Wed, 09 Apr 2008 11:43:53 +0200")
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<op.t9b7zf05wpmq96@smtp.xs4all.nl>
Message-ID: <uy77nqrkx.fsf@agharta.de>

On Wed, 09 Apr 2008 11:43:53 +0200, "Arthur Lemmens" <alemmens at xs4all.nl> wrote:

> I'm not using it yet, but a client of mine intends to start using
> this combination in the future.  So if it isn't too much trouble to
> keep the mod_lisp support, I'd appreciate it.

What is the reason the client wants to use this combination?

FWIW, I'm also in favor of removing the mod_lisp code as it will make
Hunchentoot's code base cleaner and easier to maintain.  Given that
adding mod_lisp to the mix makes your web apps much harder to debug
(IMHO of course, YMMV), I'm willing to sacrifice the performance
advantages it might have.


From arjan at streamtech.nl  Wed Apr  9 09:57:12 2008
From: arjan at streamtech.nl (Arjan Wekking)
Date: Wed, 9 Apr 2008 11:57:12 +0200
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
Message-ID: <BDFF6E5C-FB98-4F8D-9CCF-B63E4B5BE5A2@streamtech.nl>

Hello Hans,

On 9 apr 2008, at 11:39, Hans H?bner wrote:
> I'm planning to make some substantial changes to Hunchentoot and it
> would be helpful if I could remove mod_lisp support in this process.

Interesting; what are these substantial changes?

> If you are using Hunchentoot with mod_lisp, please let us know.

We (Streamtech) are using it in some relatively large web  
applications; although moving to an infrastructure without mod_lisp is  
possible, doing so would take quite some effort that we're not  
necessarily willing to take. Unless the substantial changes make up  
for it, of course ;)

-Arjan Wekking, Streamtech bv

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3405 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20080409/49e7bd7b/attachment.bin>

From edi at agharta.de  Wed Apr  9 10:07:55 2008
From: edi at agharta.de (Edi Weitz)
Date: Wed, 09 Apr 2008 12:07:55 +0200
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <BDFF6E5C-FB98-4F8D-9CCF-B63E4B5BE5A2@streamtech.nl> (Arjan
	Wekking's message of "Wed, 9 Apr 2008 11:57:12 +0200")
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<BDFF6E5C-FB98-4F8D-9CCF-B63E4B5BE5A2@streamtech.nl>
Message-ID: <utzibqr2c.fsf@agharta.de>

On Wed, 9 Apr 2008 11:57:12 +0200, Arjan Wekking <arjan at streamtech.nl> wrote:

> We (Streamtech) are using it in some relatively large web
> applications

Like in Arthur's case, I'd be interested in why you decided to go with
mod_lisp.  Just curious... :)


From xach at xach.com  Wed Apr  9 10:10:59 2008
From: xach at xach.com (Zach Beane)
Date: Wed, 9 Apr 2008 06:10:59 -0400
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <utzibqr2c.fsf@agharta.de>
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<BDFF6E5C-FB98-4F8D-9CCF-B63E4B5BE5A2@streamtech.nl>
	<utzibqr2c.fsf@agharta.de>
Message-ID: <20080409101059.GS3375@xach.com>

On Wed, Apr 09, 2008 at 12:07:55PM +0200, Edi Weitz wrote:
> On Wed, 9 Apr 2008 11:57:12 +0200, Arjan Wekking <arjan at streamtech.nl> wrote:
> 
> > We (Streamtech) are using it in some relatively large web
> > applications
> 
> Like in Arthur's case, I'd be interested in why you decided to go with
> mod_lisp.  Just curious... :)

I don't know about Arjan, but I use mod_lisp because my tbnl site used
it and I didn't feel like setting up anything new when I upgraded to
hunchentoot. I'm not against using a proxy, but, you know, inertia...

On the other hand, inertia is also against me ever actually
*upgrading* hunchentoot, now that I have it installed. The new
features would have to be *very* compelling. :)

Zach


From hans at huebner.org  Wed Apr  9 10:11:45 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Wed, 9 Apr 2008 12:11:45 +0200
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <BDFF6E5C-FB98-4F8D-9CCF-B63E4B5BE5A2@streamtech.nl>
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<BDFF6E5C-FB98-4F8D-9CCF-B63E4B5BE5A2@streamtech.nl>
Message-ID: <fd2982320804090311h5e3eb362w7131832fafa81b47@mail.gmail.com>

2008/4/9, Arjan Wekking <arjan at streamtech.nl>:
>  On 9 apr 2008, at 11:39, Hans H?bner wrote:

> > I'm planning to make some substantial changes to Hunchentoot and it
> > would be helpful if I could remove mod_lisp support in this process.

>  Interesting; what are these substantial changes?

I want to change Hunchentoot so that the threading model for request
execution is a configuration parameter, not a function of what the
Lisp implementation provides.  For my primary application, I currently
need a single threaded model where one thread both listens for
requests and executes them.  In the future, I may need to support a
thread pool.

I would also like to factor the SSL specific functionality into a
separate server class.

Removing the mod_lisp code would make overall refactoring easier, as
the mod_lisp decisions are spread all over the code.  Also, it is
harder to test changes if one has to test both with mod_lisp and http.
 Presently I am primarily looking for ways to simplify the code in
order to make it easier to change and extend.

> > If you are using Hunchentoot with mod_lisp, please let us know.

>  We (Streamtech) are using it in some relatively large web applications;
> although moving to an infrastructure without mod_lisp is possible, doing so
> would take quite some effort that we're not necessarily willing to take.
> Unless the substantial changes make up for it, of course ;)

Are there any features that you are really looking for?

-Hans


From edi at agharta.de  Wed Apr  9 10:15:37 2008
From: edi at agharta.de (Edi Weitz)
Date: Wed, 09 Apr 2008 12:15:37 +0200
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <20080409101059.GS3375@xach.com> (Zach Beane's message of "Wed,
	9 Apr 2008 06:10:59 -0400")
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<BDFF6E5C-FB98-4F8D-9CCF-B63E4B5BE5A2@streamtech.nl>
	<utzibqr2c.fsf@agharta.de> <20080409101059.GS3375@xach.com>
Message-ID: <uprszqqpi.fsf@agharta.de>

On Wed, 9 Apr 2008 06:10:59 -0400, Zach Beane <xach at xach.com> wrote:

> On the other hand, inertia is also against me ever actually
> *upgrading* hunchentoot, now that I have it installed.

That's the right spirit... :)


From edi at agharta.de  Wed Apr  9 10:22:46 2008
From: edi at agharta.de (Edi Weitz)
Date: Wed, 09 Apr 2008 12:22:46 +0200
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <fd2982320804090311h5e3eb362w7131832fafa81b47@mail.gmail.com>
	(Hans
	=?iso-8859-1?q?H=FCbner's?= message of "Wed, 9 Apr 2008 12:11:45 +0200")
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<BDFF6E5C-FB98-4F8D-9CCF-B63E4B5BE5A2@streamtech.nl>
	<fd2982320804090311h5e3eb362w7131832fafa81b47@mail.gmail.com>
Message-ID: <ulk3nqqdl.fsf@agharta.de>

On Wed, 9 Apr 2008 12:11:45 +0200, "Hans H?bner" <hans at huebner.org> wrote:

> Removing the mod_lisp code would make overall refactoring easier, as
> the mod_lisp decisions are spread all over the code.  [...]
> Presently I am primarily looking for ways to simplify the code in
> order to make it easier to change and extend.

Which is something I heartily support.  There are a lot of things I'd
like to change (but don't have the time for right now) and whenever I
look at Hunchentoot's code for more than a few seconds I'm driven to
tears by how ugly it is.  Lots of this is due to it growing
"organically" from being a thin CMUCL layer on top of mod_lisp
(ca. 2001/2002) to what it is now, and some of the "design" decisions
which probably should be revisited can only be revoked if we're
willing to sacrifice a bit of backwards compatibility here and there.


From achambers.home at googlemail.com  Wed Apr  9 10:49:56 2008
From: achambers.home at googlemail.com (Andy Chambers)
Date: Wed, 9 Apr 2008 10:49:56 +0000
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <fd2982320804090311h5e3eb362w7131832fafa81b47@mail.gmail.com>
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<BDFF6E5C-FB98-4F8D-9CCF-B63E4B5BE5A2@streamtech.nl>
	<fd2982320804090311h5e3eb362w7131832fafa81b47@mail.gmail.com>
Message-ID: <a70cc98c0804090349w54a345actea80b4e5a1be0060@mail.gmail.com>

On Wed, Apr 9, 2008 at 10:11 AM, Hans H?bner <hans at huebner.org> wrote:
>
>  Are there any features that you are really looking for?

How hard would it be to make sessions work independently of
hunchentoot?  I'd like (or rather Kenny would like) to make my openAIR
stuff work with aserve.  Aserve does have webactions but it seems to
involve more than just sessions.  They have a concept of "managed
pages" which doesn't really fit with the way I've done things so far.

I made a half-hearted attempt at just copying sessions.lisp and
specials.lisp into my own project but it seemed like if I was actually
going to make it work, I'd end up with all the same dependencies as
hunch anyway so what would be the point.

I also remember thinking it might be nice to have some of the request
accessors be methods instead of functions.  Would that be expensive in
terms of performance?  It would mean I could code my project to
hunch's interface and add defmethods to handle aserve requests
differently.

--
Andy


From edi at agharta.de  Wed Apr  9 10:58:46 2008
From: edi at agharta.de (Edi Weitz)
Date: Wed, 09 Apr 2008 12:58:46 +0200
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <a70cc98c0804090349w54a345actea80b4e5a1be0060@mail.gmail.com>
	(Andy Chambers's message of "Wed, 9 Apr 2008 10:49:56 +0000")
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<BDFF6E5C-FB98-4F8D-9CCF-B63E4B5BE5A2@streamtech.nl>
	<fd2982320804090311h5e3eb362w7131832fafa81b47@mail.gmail.com>
	<a70cc98c0804090349w54a345actea80b4e5a1be0060@mail.gmail.com>
Message-ID: <u8wznqopl.fsf@agharta.de>

On Wed, 9 Apr 2008 10:49:56 +0000, "Andy Chambers" <achambers.home at googlemail.com> wrote:

> How hard would it be to make sessions work independently of
> hunchentoot?

Depends if you want cookie-less sessions or not.  But in both cases it
shouldn't be /too/ hard, I'd say.

> I also remember thinking it might be nice to have some of the
> request accessors be methods instead of functions.

That's on my todo list as well.  But don't hold your breath.

> Would that be expensive in terms of performance?

I don't care.


From hans at huebner.org  Wed Apr  9 11:04:36 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Wed, 9 Apr 2008 13:04:36 +0200
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <a70cc98c0804090349w54a345actea80b4e5a1be0060@mail.gmail.com>
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<BDFF6E5C-FB98-4F8D-9CCF-B63E4B5BE5A2@streamtech.nl>
	<fd2982320804090311h5e3eb362w7131832fafa81b47@mail.gmail.com>
	<a70cc98c0804090349w54a345actea80b4e5a1be0060@mail.gmail.com>
Message-ID: <fd2982320804090404y46ac9891v8a1167b97165d4a2@mail.gmail.com>

2008/4/9, Andy Chambers <achambers.home at googlemail.com>:
> How hard would it be to make sessions work independently of
>  hunchentoot?  I'd like (or rather Kenny would like) to make my openAIR
>  stuff work with aserve.  Aserve does have webactions but it seems to
>  involve more than just sessions.  They have a concept of "managed
>  pages" which doesn't really fit with the way I've done things so far.
>
>  I made a half-hearted attempt at just copying sessions.lisp and
>  specials.lisp into my own project but it seemed like if I was actually
>  going to make it work, I'd end up with all the same dependencies as
>  hunch anyway so what would be the point.

I'd recommend that you implement your own session management scheme
based on cookies - It is not a hard thing to do and will propably be
easier than to factor out the sessions specific parts of Hunchentoot
into something that could be reused with Aserve.  I don't know
anything about your target audience, but if you don't try to support
people who have switched off Cookies, handling sessions is rather
easy.

>  I also remember thinking it might be nice to have some of the request
>  accessors be methods instead of functions.  Would that be expensive in
>  terms of performance?  It would mean I could code my project to
>  hunch's interface and add defmethods to handle aserve requests
>  differently.

Edi and I discussed that earlier on and it is on the list of things
that we would like to have.  The tradeoff is API simplicity.
Currently, the the request argument is optional in all accessors, thus
we can't easily make them be a generic function.

-Hans


From alemmens at xs4all.nl  Wed Apr  9 14:30:04 2008
From: alemmens at xs4all.nl (Arthur Lemmens)
Date: Wed, 09 Apr 2008 16:30:04 +0200
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <uy77nqrkx.fsf@agharta.de>
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<op.t9b7zf05wpmq96@smtp.xs4all.nl> <uy77nqrkx.fsf@agharta.de>
Message-ID: <op.t9ck8evfwpmq96@smtp.xs4all.nl>

Edi wrote:

> What is the reason the client wants to use this combination?

As opposed to running Hunchentoot stand-alone, you mean?  I don't
really know.  I guess he likes the cosy feeling of having everything
behind Apache.

> FWIW, I'm also in favor of removing the mod_lisp code as it will make
> Hunchentoot's code base cleaner and easier to maintain.

If you and Hans want to get rid of the mod_lisp stuff, don't let me
stop you guys.

Arthur



From hans at huebner.org  Wed Apr  9 14:32:26 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Wed, 9 Apr 2008 16:32:26 +0200
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <op.t9ck8evfwpmq96@smtp.xs4all.nl>
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<op.t9b7zf05wpmq96@smtp.xs4all.nl> <uy77nqrkx.fsf@agharta.de>
	<op.t9ck8evfwpmq96@smtp.xs4all.nl>
Message-ID: <fd2982320804090732v7a889ceft5e115553ca9b4a79@mail.gmail.com>

2008/4/9, Arthur Lemmens <alemmens at xs4all.nl>:
> Edi wrote:
>
>  > What is the reason the client wants to use this combination?
>
>
> As opposed to running Hunchentoot stand-alone, you mean?  I don't
>  really know.  I guess he likes the cosy feeling of having everything
>  behind Apache.

You may be able to convince them that running Hunchentoot in HTTP mode
behind Apache configured as transparent proxy is as cosy.

Cheers,
Hans


From alemmens at xs4all.nl  Wed Apr  9 14:37:52 2008
From: alemmens at xs4all.nl (Arthur Lemmens)
Date: Wed, 09 Apr 2008 16:37:52 +0200
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <fd2982320804090732v7a889ceft5e115553ca9b4a79@mail.gmail.com>
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<op.t9b7zf05wpmq96@smtp.xs4all.nl> <uy77nqrkx.fsf@agharta.de>
	<op.t9ck8evfwpmq96@smtp.xs4all.nl>
	<fd2982320804090732v7a889ceft5e115553ca9b4a79@mail.gmail.com>
Message-ID: <op.t9clleoiwpmq96@smtp.xs4all.nl>

Hans H?bner wrote:

> You may be able to convince them that running Hunchentoot in HTTP mode
> behind Apache configured as transparent proxy is as cosy.

Thanks for the suggestion.  I'll look into that when my client wants me
to start working on the web part of his application.

Arthur



From edi at agharta.de  Wed Apr  9 14:50:12 2008
From: edi at agharta.de (Edi Weitz)
Date: Wed, 09 Apr 2008 16:50:12 +0200
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <op.t9ck8evfwpmq96@smtp.xs4all.nl> (Arthur Lemmens's message of
	"Wed, 09 Apr 2008 16:30:04 +0200")
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<op.t9b7zf05wpmq96@smtp.xs4all.nl> <uy77nqrkx.fsf@agharta.de>
	<op.t9ck8evfwpmq96@smtp.xs4all.nl>
Message-ID: <umyo3ozff.fsf@agharta.de>

On Wed, 09 Apr 2008 16:30:04 +0200, "Arthur Lemmens" <alemmens at xs4all.nl> wrote:

> As opposed to running Hunchentoot stand-alone, you mean?  I don't
> really know.  I guess he likes the cosy feeling of having everything
> behind Apache.

You don't need mod_lisp for that.  You can put Hunchentoot behind
mod_proxy as described in the documentation.  That way, you still have
a pure Lisp server for testing and debugging, but it is shielded from
the Real World[tm] outside by an Apache.  I'm doing that all the time.

  http://weitz.de/hunchentoot/#proxy


From alemmens at xs4all.nl  Wed Apr  9 14:58:22 2008
From: alemmens at xs4all.nl (Arthur Lemmens)
Date: Wed, 09 Apr 2008 16:58:22 +0200
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <umyo3ozff.fsf@agharta.de>
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<op.t9b7zf05wpmq96@smtp.xs4all.nl> <uy77nqrkx.fsf@agharta.de>
	<op.t9ck8evfwpmq96@smtp.xs4all.nl> <umyo3ozff.fsf@agharta.de>
Message-ID: <op.t9cmjkqzwpmq96@smtp.xs4all.nl>

Edi wrote:

> You don't need mod_lisp for that.  You can put Hunchentoot behind
> mod_proxy as described in the documentation.  That way, you still have
> a pure Lisp server for testing and debugging, but it is shielded from
> the Real World[tm] outside by an Apache.

I see.  Thanks for the info.

Arthur



From ch-tbnl at bobobeach.com  Wed Apr  9 15:06:00 2008
From: ch-tbnl at bobobeach.com (Cyrus Harmon)
Date: Wed, 9 Apr 2008 08:06:00 -0700
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <a70cc98c0804090349w54a345actea80b4e5a1be0060@mail.gmail.com>
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<BDFF6E5C-FB98-4F8D-9CCF-B63E4B5BE5A2@streamtech.nl>
	<fd2982320804090311h5e3eb362w7131832fafa81b47@mail.gmail.com>
	<a70cc98c0804090349w54a345actea80b4e5a1be0060@mail.gmail.com>
Message-ID: <6E4B9D46-8251-4CA0-A8E0-D8303751298A@bobobeach.com>

If I understand what you're saying, the openAIR stuff currently works  
on hunchentoot and there is a desire to see it ported to aserve. Just  
curious, but what is the motivation for wanting to use aserve? Is it a  
performance issue? installed base? etc...

thanks,

Cyrus

On Apr 9, 2008, at 3:49 AM, Andy Chambers wrote:

> On Wed, Apr 9, 2008 at 10:11 AM, Hans H?bner <hans at huebner.org> wrote:
>>
>> Are there any features that you are really looking for?
>
> How hard would it be to make sessions work independently of
> hunchentoot?  I'd like (or rather Kenny would like) to make my openAIR
> stuff work with aserve.  Aserve does have webactions but it seems to
> involve more than just sessions.  They have a concept of "managed
> pages" which doesn't really fit with the way I've done things so far.
>
> I made a half-hearted attempt at just copying sessions.lisp and
> specials.lisp into my own project but it seemed like if I was actually
> going to make it work, I'd end up with all the same dependencies as
> hunch anyway so what would be the point.
>
> I also remember thinking it might be nice to have some of the request
> accessors be methods instead of functions.  Would that be expensive in
> terms of performance?  It would mean I could code my project to
> hunch's interface and add defmethods to handle aserve requests
> differently.
>
> --
> Andy
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel



From rm at seid-online.de  Wed Apr  9 15:09:34 2008
From: rm at seid-online.de (Ralf Mattes)
Date: Wed, 09 Apr 2008 17:09:34 +0200
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <umyo3ozff.fsf@agharta.de>
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<op.t9b7zf05wpmq96@smtp.xs4all.nl> <uy77nqrkx.fsf@agharta.de>
	<op.t9ck8evfwpmq96@smtp.xs4all.nl>  <umyo3ozff.fsf@agharta.de>
Message-ID: <1207753775.6581.7.camel@localhost.localdomain>

On Wed, 2008-04-09 at 16:50 +0200, Edi Weitz wrote:
> On Wed, 09 Apr 2008 16:30:04 +0200, "Arthur Lemmens" <alemmens at xs4all.nl> wrote:
> 
> > As opposed to running Hunchentoot stand-alone, you mean?  I don't
> > really know.  I guess he likes the cosy feeling of having everything
> > behind Apache.
> 
> You don't need mod_lisp for that.  You can put Hunchentoot behind
> mod_proxy as described in the documentation.  That way, you still have
> a pure Lisp server for testing and debugging, but it is shielded from
> the Real World[tm] outside by an Apache.

Yes, that' s true iff you need Apache just for that cozzy feelin'
But often there's much more built into the Apache server, like
Authentication, Authorisation, session handling etc. that needs to be
shared with other Apache modules. Sometimes it's possible to tweak
Apache in order to use mod_proxy but often that isn't the case. 

 Cheers, Ralf Mattes
 



From edi at agharta.de  Wed Apr  9 15:19:14 2008
From: edi at agharta.de (Edi Weitz)
Date: Wed, 09 Apr 2008 17:19:14 +0200
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <6E4B9D46-8251-4CA0-A8E0-D8303751298A@bobobeach.com> (Cyrus
	Harmon's message of "Wed, 9 Apr 2008 08:06:00 -0700")
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<BDFF6E5C-FB98-4F8D-9CCF-B63E4B5BE5A2@streamtech.nl>
	<fd2982320804090311h5e3eb362w7131832fafa81b47@mail.gmail.com>
	<a70cc98c0804090349w54a345actea80b4e5a1be0060@mail.gmail.com>
	<6E4B9D46-8251-4CA0-A8E0-D8303751298A@bobobeach.com>
Message-ID: <uabk3oy31.fsf@agharta.de>

On Wed, 9 Apr 2008 08:06:00 -0700, Cyrus Harmon <ch-tbnl at bobobeach.com> wrote:

> If I understand what you're saying, the openAIR stuff currently
> works on hunchentoot and there is a desire to see it ported to
> aserve. Just curious, but what is the motivation for wanting to use
> aserve?

Probably Kenny's fondness for AllegroCL... :)


From edi at agharta.de  Wed Apr  9 15:21:42 2008
From: edi at agharta.de (Edi Weitz)
Date: Wed, 09 Apr 2008 17:21:42 +0200
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <1207753775.6581.7.camel@localhost.localdomain> (Ralf Mattes's
	message of "Wed, 09 Apr 2008 17:09:34 +0200")
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<op.t9b7zf05wpmq96@smtp.xs4all.nl> <uy77nqrkx.fsf@agharta.de>
	<op.t9ck8evfwpmq96@smtp.xs4all.nl> <umyo3ozff.fsf@agharta.de>
	<1207753775.6581.7.camel@localhost.localdomain>
Message-ID: <u3apvoxyx.fsf@agharta.de>

On Wed, 09 Apr 2008 17:09:34 +0200, Ralf Mattes <rm at seid-online.de> wrote:

> Yes, that' s true iff you need Apache just for that cozzy feelin'
> But often there's much more built into the Apache server, like
> Authentication, Authorisation, session handling etc. that needs to
> be shared with other Apache modules. Sometimes it's possible to
> tweak Apache in order to use mod_proxy but often that isn't the
> case.

Was that an argument pro mod_lisp?


From hans at huebner.org  Wed Apr  9 15:22:00 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Wed, 9 Apr 2008 17:22:00 +0200
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <1207753775.6581.7.camel@localhost.localdomain>
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<op.t9b7zf05wpmq96@smtp.xs4all.nl> <uy77nqrkx.fsf@agharta.de>
	<op.t9ck8evfwpmq96@smtp.xs4all.nl> <umyo3ozff.fsf@agharta.de>
	<1207753775.6581.7.camel@localhost.localdomain>
Message-ID: <fd2982320804090822je9f4b6we915b54472f65afc@mail.gmail.com>

2008/4/9, Ralf Mattes <rm at seid-online.de>:
>  But often there's much more built into the Apache server, like
>  Authentication, Authorisation, session handling etc. that needs to be
>  shared with other Apache modules. Sometimes it's possible to tweak
>  Apache in order to use mod_proxy but often that isn't the case.

This is a good reason not to abandon mod_lisp support.

-Hans


From rm at seid-online.de  Wed Apr  9 15:24:30 2008
From: rm at seid-online.de (Ralf Mattes)
Date: Wed, 09 Apr 2008 17:24:30 +0200
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <u3apvoxyx.fsf@agharta.de>
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<op.t9b7zf05wpmq96@smtp.xs4all.nl> <uy77nqrkx.fsf@agharta.de>
	<op.t9ck8evfwpmq96@smtp.xs4all.nl> <umyo3ozff.fsf@agharta.de>
	<1207753775.6581.7.camel@localhost.localdomain>
	<u3apvoxyx.fsf@agharta.de>
Message-ID: <1207754670.6581.10.camel@localhost.localdomain>

On Wed, 2008-04-09 at 17:21 +0200, Edi Weitz wrote:
> On Wed, 09 Apr 2008 17:09:34 +0200, Ralf Mattes <rm at seid-online.de> wrote:
> 
> > Yes, that' s true iff you need Apache just for that cozzy feelin'
> > But often there's much more built into the Apache server, like
> > Authentication, Authorisation, session handling etc. that needs to
> > be shared with other Apache modules. Sometimes it's possible to
> > tweak Apache in order to use mod_proxy but often that isn't the
> > case.
> 
> Was that an argument pro mod_lisp?

Yes, I _thought_ that was clear. I've to admit that we are currently not
using mod_lisp, just the standalone version, but it gives me a cozzy
feeling to know that I _could_ get tighter integration once need arises.

 Cheers, RalfD




From arjan at streamtech.nl  Wed Apr  9 15:27:51 2008
From: arjan at streamtech.nl (Arjan Wekking)
Date: Wed, 9 Apr 2008 17:27:51 +0200
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <utzibqr2c.fsf@agharta.de>
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<BDFF6E5C-FB98-4F8D-9CCF-B63E4B5BE5A2@streamtech.nl>
	<utzibqr2c.fsf@agharta.de>
Message-ID: <E86AFFE1-2930-432C-8962-573B2129F4A1@streamtech.nl>

On 9 apr 2008, at 12:07, Edi Weitz wrote:

> On Wed, 9 Apr 2008 11:57:12 +0200, Arjan Wekking  
> <arjan at streamtech.nl> wrote:
>
>> We (Streamtech) are using it in some relatively large web
>> applications
>
> Like in Arthur's case, I'd be interested in why you decided to go with
> mod_lisp.  Just curious... :)

Well, it's partially historical (we moved some parts of the  
application from UCW to hunchentoot, keeping the mod_lisp set up as it  
was) and to a certain degree because of performance (we've been doing  
an average 6 requests per second 24/7 on the main part of our  
application).

Keeping Apache in front of Lisp has turned out to be a very pleasant  
setup for both performance (we serve quite some static files as well)  
and run-time management (to configure HTTP processing details, dealing  
with name bases virtual hosting and moving apps around without any  
downtime). We know this works just as well when running behind  
mod_proxy (as Zach mentioned) so we're not really depending on  
mod_lisp for that.

So, to sum things up; we know mod_lisp is a very thin layer compared  
to just proxying HTTP requests and we've been thinking of taking it  
out on some occasions (the behaviour it displays when restarting a  
Lisp without restarting Apache has been an issue now and then) so if  
mod_lisp support was dropped we would eventually change to a mod_proxy  
set up when we want to upgrade Hunchentoot, I guess.


-Arjan Wekking, Streamtech bv

-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3405 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20080409/29626ffd/attachment.bin>

From edi at agharta.de  Wed Apr  9 15:34:27 2008
From: edi at agharta.de (Edi Weitz)
Date: Wed, 09 Apr 2008 17:34:27 +0200
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <1207754670.6581.10.camel@localhost.localdomain> (Ralf Mattes's
	message of "Wed, 09 Apr 2008 17:24:30 +0200")
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<op.t9b7zf05wpmq96@smtp.xs4all.nl> <uy77nqrkx.fsf@agharta.de>
	<op.t9ck8evfwpmq96@smtp.xs4all.nl> <umyo3ozff.fsf@agharta.de>
	<1207753775.6581.7.camel@localhost.localdomain>
	<u3apvoxyx.fsf@agharta.de>
	<1207754670.6581.10.camel@localhost.localdomain>
Message-ID: <uy77nnit8.fsf@agharta.de>

On Wed, 09 Apr 2008 17:24:30 +0200, Ralf Mattes <rm at seid-online.de> wrote:

> Yes, I _thought_ that was clear. I've to admit that we are currently
> not using mod_lisp, just the standalone version, but it gives me a
> cozzy feeling to know that I _could_ get tighter integration once
> need arises.

Have you actually used mod_lisp for something like that before?  I
asked because I couldn't really come up with a convincing case where
you'd get tighter Apache integration that way.  I've done quite a lot
of Apache hacking in my pre-Lisp life, but working with something like
mod_perl or writing your own modules in C is certainly different from
using mod_lisp.


From hans at huebner.org  Wed Apr  9 16:03:11 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Wed, 9 Apr 2008 18:03:11 +0200
Subject: [hunchentoot-devel] Refactoring work plan
Message-ID: <fd2982320804090903t16361b1i9c1b664d26c3a6ee@mail.gmail.com>

I spent much of today looking at Hunchentoot and here is my plan for
refactoring:

Immediate high level goals:

- Make threading optional on threaded platforms
- Prepare for SERVE-EVENT based buffering
- Clean up and refactor for better hackability

In the longer term, I would like to make more of Hunchentoots data
structures into classes that can be subclassed by applications.
Requests, sessions and handlers come to mind, all of which currently
exist, but they can't easily be extended in an object oriented
fashion.  Maybe it is good like that and an object oriented framework
should be made optional.  Also, there should be a logging API.

Short term hacking plan:

- Use USOCKET instead of private compatibility library.  Currently,
threading and socket I/O is intermixed because COMM:START-UP-SERVER
from Lispworks is emulated by all platforms.  Also, timeouts will be
provided through USOCKET.
- Use BORDEAUX-THREADS for threading.  Currently, threads are assumed
to be processes as in Lispworks.  I particularily dislike the use of
PROCESS-KILL to shutdown the server.
- Clean up and refactor to reduce the number of special variables
- Move platform specific code into subdirectory
- Once we have decided whether we want to keep mod_lisp:  Refactor so
that mod_lisp specific code is isolated or remove it altogether.

If you think anything of this is terrible and/or a bad idea, speak up.

-Hans


From rsynnott at gmail.com  Wed Apr  9 17:04:22 2008
From: rsynnott at gmail.com (Robert Synnott)
Date: Wed, 9 Apr 2008 18:04:22 +0100
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <fd2982320804090404y46ac9891v8a1167b97165d4a2@mail.gmail.com>
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<BDFF6E5C-FB98-4F8D-9CCF-B63E4B5BE5A2@streamtech.nl>
	<fd2982320804090311h5e3eb362w7131832fafa81b47@mail.gmail.com>
	<a70cc98c0804090349w54a345actea80b4e5a1be0060@mail.gmail.com>
	<fd2982320804090404y46ac9891v8a1167b97165d4a2@mail.gmail.com>
Message-ID: <24f203480804091004k2f8ad7bbjb1bb9d6b639b9618@mail.gmail.com>

On Wed, Apr 9, 2008 at 12:04 PM, Hans H?bner <hans at huebner.org> wrote:
> 2008/4/9, Andy Chambers <achambers.home at googlemail.com>:
>
> > How hard would it be to make sessions work independently of
>  >  hunchentoot?  I'd like (or rather Kenny would like) to make my openAIR
>  >  stuff work with aserve.  Aserve does have webactions but it seems to
>  >  involve more than just sessions.  They have a concept of "managed
>  >  pages" which doesn't really fit with the way I've done things so far.
>  >
>  >  I made a half-hearted attempt at just copying sessions.lisp and
>  >  specials.lisp into my own project but it seemed like if I was actually
>  >  going to make it work, I'd end up with all the same dependencies as
>  >  hunch anyway so what would be the point.
>
>  I'd recommend that you implement your own session management scheme
>  based on cookies - It is not a hard thing to do and will propably be
>  easier than to factor out the sessions specific parts of Hunchentoot
>  into something that could be reused with Aserve.  I don't know
>  anything about your target audience, but if you don't try to support
>  people who have switched off Cookies, handling sessions is rather
>  easy.
>
>
The current sessions aren't suited to all cases, anyway; in
particular, they're not suitable for a system with multiple frontend
machines unless you're binding users to a specific machine on login
(which carries its own problems with it).
Rob.


From kiuma72 at gmail.com  Wed Apr  9 17:06:22 2008
From: kiuma72 at gmail.com (Andrea Chiumenti)
Date: Wed, 9 Apr 2008 19:06:22 +0200
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <uy77nnit8.fsf@agharta.de>
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<op.t9b7zf05wpmq96@smtp.xs4all.nl> <uy77nqrkx.fsf@agharta.de>
	<op.t9ck8evfwpmq96@smtp.xs4all.nl> <umyo3ozff.fsf@agharta.de>
	<1207753775.6581.7.camel@localhost.localdomain>
	<u3apvoxyx.fsf@agharta.de>
	<1207754670.6581.10.camel@localhost.localdomain>
	<uy77nnit8.fsf@agharta.de>
Message-ID: <4d3bc9370804091006r42bfaceep7ad85988a358e77f@mail.gmail.com>

In my case, as I'm developing CLAW, using mod_proxy instead of mod_lisp
shouldn't be a problem.

On Wed, Apr 9, 2008 at 5:34 PM, Edi Weitz <edi at agharta.de> wrote:
> On Wed, 09 Apr 2008 17:24:30 +0200, Ralf Mattes <rm at seid-online.de> wrote:
>
>  > Yes, I _thought_ that was clear. I've to admit that we are currently
>  > not using mod_lisp, just the standalone version, but it gives me a
>  > cozzy feeling to know that I _could_ get tighter integration once
>  > need arises.
>
>  Have you actually used mod_lisp for something like that before?  I
>  asked because I couldn't really come up with a convincing case where
>  you'd get tighter Apache integration that way.  I've done quite a lot
>  of Apache hacking in my pre-Lisp life, but working with something like
>  mod_perl or writing your own modules in C is certainly different from
>  using mod_lisp.
>
>
> _______________________________________________
>  tbnl-devel site list
>  tbnl-devel at common-lisp.net
>  http://common-lisp.net/mailman/listinfo/tbnl-devel
>


From kiuma72 at gmail.com  Wed Apr  9 17:11:27 2008
From: kiuma72 at gmail.com (Andrea Chiumenti)
Date: Wed, 9 Apr 2008 19:11:27 +0200
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <4d3bc9370804091006r42bfaceep7ad85988a358e77f@mail.gmail.com>
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<op.t9b7zf05wpmq96@smtp.xs4all.nl> <uy77nqrkx.fsf@agharta.de>
	<op.t9ck8evfwpmq96@smtp.xs4all.nl> <umyo3ozff.fsf@agharta.de>
	<1207753775.6581.7.camel@localhost.localdomain>
	<u3apvoxyx.fsf@agharta.de>
	<1207754670.6581.10.camel@localhost.localdomain>
	<uy77nnit8.fsf@agharta.de>
	<4d3bc9370804091006r42bfaceep7ad85988a358e77f@mail.gmail.com>
Message-ID: <4d3bc9370804091011t583c627sf0785e65973f57cc@mail.gmail.com>

It should also be nice if you consider to adapt the session realm
logic (if it is the case) that I've adopted overriding hunchentoot in
CLAW, so that I can
remove the overriding file from my project.

On Wed, Apr 9, 2008 at 7:06 PM, Andrea Chiumenti <kiuma72 at gmail.com> wrote:
> In my case, as I'm developing CLAW, using mod_proxy instead of mod_lisp
>  shouldn't be a problem.
>
>
>
>  On Wed, Apr 9, 2008 at 5:34 PM, Edi Weitz <edi at agharta.de> wrote:
>  > On Wed, 09 Apr 2008 17:24:30 +0200, Ralf Mattes <rm at seid-online.de> wrote:
>  >
>  >  > Yes, I _thought_ that was clear. I've to admit that we are currently
>  >  > not using mod_lisp, just the standalone version, but it gives me a
>  >  > cozzy feeling to know that I _could_ get tighter integration once
>  >  > need arises.
>  >
>  >  Have you actually used mod_lisp for something like that before?  I
>  >  asked because I couldn't really come up with a convincing case where
>  >  you'd get tighter Apache integration that way.  I've done quite a lot
>  >  of Apache hacking in my pre-Lisp life, but working with something like
>  >  mod_perl or writing your own modules in C is certainly different from
>  >  using mod_lisp.
>  >
>  >
>  > _______________________________________________
>  >  tbnl-devel site list
>  >  tbnl-devel at common-lisp.net
>  >  http://common-lisp.net/mailman/listinfo/tbnl-devel
>  >
>


From vseguip at gmail.com  Wed Apr  9 17:49:29 2008
From: vseguip at gmail.com (vseguip at gmail.com)
Date: Wed, 9 Apr 2008 19:49:29 +0200
Subject: [hunchentoot-devel] Refactoring work plan
In-Reply-To: <fd2982320804090903t16361b1i9c1b664d26c3a6ee@mail.gmail.com>
References: <fd2982320804090903t16361b1i9c1b664d26c3a6ee@mail.gmail.com>
Message-ID: <dda3b98e0804091049s2999d9ap47648602a48af619@mail.gmail.com>

On Wed, Apr 9, 2008 at 6:03 PM, Hans H?bner <hans at huebner.org> wrote:
> I spent much of today looking at Hunchentoot and here is my plan for
>  refactoring:
>
>  Immediate high level goals:
>
>  - Make threading optional on threaded platforms
>  - Prepare for SERVE-EVENT based buffering
>  - Clean up and refactor for better hackability
>
>  In the longer term, I would like to make more of Hunchentoots data
>  structures into classes that can be subclassed by applications.
>  Requests, sessions and handlers come to mind, all of which currently
>  exist, but they can't easily be extended in an object oriented
>  fashion.  Maybe it is good like that and an object oriented framework
>  should be made optional.  Also, there should be a logging API.
>
>

Hi,
  I'm a total Lisp (and Hunchentoot) noob so what is coming may well
be total nonsense.
 I took a look at hunchentoot code some time ago, and started some
refactoring (I had to abandon it due to a total lack of time) which I
would like to comment with you (and maybe help if Iyou decide to try
it). The basic idea was to implement Hunchentoot's process-connection
as a generic method on a generic connection class. Then we could add
layers&transports as simple classes using CLOS :around method dispatch
mechanism. For instance we could have an http_connection, mod_lisp,
mod_fcgi, https_connection as a top layer class. Then we could have a
chunga_stream, flexi_stream class that adds chunked stream capability,
etc. Hunchentoot users could create flexible server doing something
like (defclass fcgi-server (mod_fcgi  chunga-stream flexi-stream)),
etc. As I said I don't know if this is sane at all, but I thought I
would share my 2 cents anyway.


Cheers,
  vseguip

From kimstebel at gmx.de  Wed Apr  9 20:11:02 2008
From: kimstebel at gmx.de (Kim Stebel)
Date: Wed, 09 Apr 2008 22:11:02 +0200
Subject: [hunchentoot-devel] problem setting up hunchentoot
Message-ID: <op.t9c00omuqjq2m8@kim-laptop>

Hello group,

I'm new to LISP and i'm trying to set up a basic "Hello World"-website
with Hunchentoot. I'm using SBCL 1.0.6 on linux(ubuntu gutsy) and  
installed hunchentoot
via asdf-install. Then i registered a file handler and startet the
server:
(require :hunchentoot)
(setq hunchentoot:*dispatch-table*
       (list (hunchentoot:create-static-file-dispatcher-and-handler "/
htt" "/home/kim/httest.html")))
(defvar *ht-server* (hunchentoot:start-server :port 3456))

The problem: No page is displayed when I tell my browser to go to
"localhost:3456/htt". Telneting to port 3456 always results in the
connection being closed immediately without an error message.
I googled quite a lot and tried the following to get more information:

(setq hunchentoot:*SHOW-LISP-ERRORS-P* t)
(setq hunchentoot:*SHOW-LISP-BACKTRACES-P* t)
(setq hunchentoot:*catch-errors-p* nil)

Now each time I try to connect to hunchentoot, I get the following
error message in the REPL:
debugger invoked on a UNDEFINED-FUNCTION in thread #<THREAD
"hunchentoot-worker-4" {B2271F9}>:
   The function (SETF HUNCHENTOOT::FLEXI-STREAM-BOUND) is undefined.

I already sent this to comp.lang.lisp  
(http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/383c828c94adc557#)  
and the nice people there helped me to ensure that all the required  
components are installed and loaded.
I also tried the example from http://weitz.de/hunchentoot/#example and got  
the same error message.
I'm pretty lost here, so I'd really appreciate any help.
Thanks in advance
Kim


From hans at huebner.org  Wed Apr  9 20:40:08 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Wed, 9 Apr 2008 22:40:08 +0200
Subject: [hunchentoot-devel] problem setting up hunchentoot
In-Reply-To: <op.t9c00omuqjq2m8@kim-laptop>
References: <op.t9c00omuqjq2m8@kim-laptop>
Message-ID: <fd2982320804091340q24d14ba5h1537acfed5eb548d@mail.gmail.com>

Hi Kim,

do you have the latest version of Flexi-Streams and all other
dependent libraries installed?  I have flexi-streams-0.13.1 - it does
indeed have the FLEXI-STREAM-BOUND function and it also exports the
function properly.  It is my guess that you have an older version.

If you want to save some time, you may want to check out
svn://svn.bknr.net/svn/trunk/thirdparty to get running quickly
(currently, this requires 141MB).

-Hans

2008/4/9, Kim Stebel <kimstebel at gmx.de>:
> Hello group,
>
>  I'm new to LISP and i'm trying to set up a basic "Hello World"-website
>  with Hunchentoot. I'm using SBCL 1.0.6 on linux(ubuntu gutsy) and installed
> hunchentoot
>  via asdf-install. Then i registered a file handler and startet the
>  server:
>  (require :hunchentoot)
>  (setq hunchentoot:*dispatch-table*
>       (list
> (hunchentoot:create-static-file-dispatcher-and-handler "/
>  htt" "/home/kim/httest.html")))
>  (defvar *ht-server* (hunchentoot:start-server :port 3456))
>
>  The problem: No page is displayed when I tell my browser to go to
>  "localhost:3456/htt". Telneting to port 3456 always results in the
>  connection being closed immediately without an error message.
>  I googled quite a lot and tried the following to get more information:
>
>  (setq hunchentoot:*SHOW-LISP-ERRORS-P* t)
>  (setq hunchentoot:*SHOW-LISP-BACKTRACES-P* t)
>  (setq hunchentoot:*catch-errors-p* nil)
>
>  Now each time I try to connect to hunchentoot, I get the following
>  error message in the REPL:
>  debugger invoked on a UNDEFINED-FUNCTION in thread #<THREAD
>  "hunchentoot-worker-4" {B2271F9}>:
>   The function (SETF HUNCHENTOOT::FLEXI-STREAM-BOUND) is
> undefined.
>
>  I already sent this to comp.lang.lisp
> (http://groups.google.com/group/comp.lang.lisp/browse_thread/thread/383c828c94adc557#)
> and the nice people there helped me to ensure that all the required
> components are installed and loaded.
>  I also tried the example from
> http://weitz.de/hunchentoot/#example and got the same error
> message.
>  I'm pretty lost here, so I'd really appreciate any help.
>  Thanks in advance
>  Kim
>  _______________________________________________
>  tbnl-devel site list
>  tbnl-devel at common-lisp.net
>  http://common-lisp.net/mailman/listinfo/tbnl-devel
>


From edi at agharta.de  Wed Apr  9 20:58:49 2008
From: edi at agharta.de (Edi Weitz)
Date: Wed, 09 Apr 2008 22:58:49 +0200
Subject: [hunchentoot-devel] problem setting up hunchentoot
In-Reply-To: <op.t9c00omuqjq2m8@kim-laptop> (Kim Stebel's message of "Wed,
	09 Apr 2008 22:11:02 +0200")
References: <op.t9c00omuqjq2m8@kim-laptop>
Message-ID: <uhceaoid2.fsf@agharta.de>

On Wed, 09 Apr 2008 22:11:02 +0200, "Kim Stebel" <kimstebel at gmx.de> wrote:

>    The function (SETF HUNCHENTOOT::FLEXI-STREAM-BOUND) is undefined.

As Hans already said, this very likely means that your version of
FLEXI-STREAMS is too old.  From what you posted to c.l.l, it looks as
if you're using libraries distributed by Debian or Ubuntu or something
like that which would be the reason.

To fix thix, you'll have to get rid of the Debian-installed libraries
(to make sure they don't get in your way) and downloaded the latest
versions from the appropriate places.

Sorry for the inconvenience, but if my analysis is correct, then this
is really not an issue with the libraries but rather with your OS and
its packaging system.


From edi at agharta.de  Wed Apr  9 21:16:49 2008
From: edi at agharta.de (Edi Weitz)
Date: Wed, 09 Apr 2008 23:16:49 +0200
Subject: [hunchentoot-devel] Re: Refactoring work plan
In-Reply-To: <fd2982320804090903t16361b1i9c1b664d26c3a6ee@mail.gmail.com> (Hans
	=?iso-8859-1?q?H=FCbner's?= message of "Wed, 9 Apr 2008 18:03:11 +0200")
References: <fd2982320804090903t16361b1i9c1b664d26c3a6ee@mail.gmail.com>
Message-ID: <u8wzmohj2.fsf@agharta.de>

On Wed, 9 Apr 2008 18:03:11 +0200, "Hans H?bner" <hans at huebner.org> wrote:

> Immediate high level goals:
>
> - Make threading optional on threaded platforms
> - Prepare for SERVE-EVENT based buffering
> - Clean up and refactor for better hackability

I agree with all of these.

> In the longer term, I would like to make more of Hunchentoots data
> structures into classes that can be subclassed by applications.
> Requests, sessions and handlers come to mind, all of which currently
> exist, but they can't easily be extended in an object oriented
> fashion.  Maybe it is good like that and an object oriented
> framework should be made optional.

This was on my todo list anyway.  I'm currently thinking that (for
example) REMOTE-ADDR should be a plain function with one optional
argument which calls a generic function REMOTE-ADDR% (or however it's
named) with one required argument which is also exported.  That would
look a bit bloated initially, but it'd be backwards-compatible and
convenient for most users while those who want/need it, can go "one
level down" and specialize the generic functions.

> Also, there should be a logging API.

I haven't really looked at the available logging libs yet.  Would it
make sense to use one of those?  The current implementation certainly
has a couple of flaws.

> - Use USOCKET instead of private compatibility library.  Currently,
> threading and socket I/O is intermixed because COMM:START-UP-SERVER
> from Lispworks is emulated by all platforms.  Also, timeouts will be
> provided through USOCKET.

Hunchentoot spent the first year of its life as a LispWork-only
library... :)

> - Use BORDEAUX-THREADS for threading.  Currently, threads are
> assumed to be processes as in Lispworks.  I particularily dislike
> the use of PROCESS-KILL to shutdown the server.

That's the documented way to stop a server on LW:

  http://www.lispworks.com/documentation/lw51/LWRM/html/lwref-61.htm

> - Clean up and refactor to reduce the number of special variables

Yep.

> - Move platform specific code into subdirectory

Yep.

> - Once we have decided whether we want to keep mod_lisp: Refactor so
> that mod_lisp specific code is isolated or remove it altogether.

Maybe it's sufficient if you provide support to implement a mod_lisp
"backend" without actually doing it yourself.  If there's enough
demand, then someone will (hopefully) add the necessary code.

> If you think anything of this is terrible and/or a bad idea, speak
> up.

Sounds great to me.  Except that after all of this, Hunchentoot will
be your library and not mine anymore.  But that's also fine with
me... :)


From kimstebel at gmx.de  Wed Apr  9 21:19:48 2008
From: kimstebel at gmx.de (Kim Stebel)
Date: Wed, 09 Apr 2008 23:19:48 +0200
Subject: [hunchentoot-devel] problem setting up hunchentoot
In-Reply-To: <uhceaoid2.fsf@agharta.de>
References: <op.t9c00omuqjq2m8@kim-laptop> <uhceaoid2.fsf@agharta.de>
Message-ID: <op.t9c37azuqjq2m8@kim-laptop>


> To fix thix, you'll have to get rid of the Debian-installed libraries
> (to make sure they don't get in your way) and downloaded the latest
> versions from the appropriate places.
>
> Sorry for the inconvenience, but if my analysis is correct, then this
> is really not an issue with the libraries but rather with your OS and
> its packaging system.

Thanks for your reply. The problem is solved. I removed the ubuntu version  
of the library and just did (asdf-install:install :hunchentoot) again. Now  
it works fine. I agree that this is a problem with ubuntu, but shouldn't  
have asdf-install told me I don't have the right version? As I understand  
it, it's asdf-install's job to check dependencies before installing.
Thanks again
Kim




From edi at agharta.de  Wed Apr  9 21:33:35 2008
From: edi at agharta.de (Edi Weitz)
Date: Wed, 09 Apr 2008 23:33:35 +0200
Subject: [hunchentoot-devel] problem setting up hunchentoot
In-Reply-To: <op.t9c37azuqjq2m8@kim-laptop> (Kim Stebel's message of "Wed,
	09 Apr 2008 23:19:48 +0200")
References: <op.t9c00omuqjq2m8@kim-laptop> <uhceaoid2.fsf@agharta.de>
	<op.t9c37azuqjq2m8@kim-laptop>
Message-ID: <u4paalnm8.fsf@agharta.de>

On Wed, 09 Apr 2008 23:19:48 +0200, "Kim Stebel" <kimstebel at gmx.de> wrote:

> I agree that this is a problem with ubuntu, but shouldn't have
> asdf-install told me I don't have the right version? As I understand
> it, it's asdf-install's job to check dependencies before installing.

How is ASDF-INSTALL supposed to know about the Ubuntu libraries?  You
didn't expect it to scan your whole hard disk, did you?

Also, neither ASDF nor ASDF-INSTALL do any version checking AFAIK.
They just check if the required libs are there.


From kimstebel at gmx.de  Wed Apr  9 21:42:53 2008
From: kimstebel at gmx.de (Kim Stebel)
Date: Wed, 09 Apr 2008 23:42:53 +0200
Subject: [hunchentoot-devel] problem setting up hunchentoot
In-Reply-To: <u4paalnm8.fsf@agharta.de>
References: <op.t9c00omuqjq2m8@kim-laptop> <uhceaoid2.fsf@agharta.de>
	<op.t9c37azuqjq2m8@kim-laptop> <u4paalnm8.fsf@agharta.de>
Message-ID: <op.t9c49rc9qjq2m8@kim-laptop>

On Wed, 09 Apr 2008 23:33:35 +0200, Edi Weitz <edi at agharta.de> wrote:

> On Wed, 09 Apr 2008 23:19:48 +0200, "Kim Stebel" <kimstebel at gmx.de>  
> wrote:
>
>> I agree that this is a problem with ubuntu, but shouldn't have
>> asdf-install told me I don't have the right version? As I understand
>> it, it's asdf-install's job to check dependencies before installing.
>
> How is ASDF-INSTALL supposed to know about the Ubuntu libraries?  You
> didn't expect it to scan your whole hard disk, did you?
Well the ubuntu-libs are installed to the standard sbcl dir and  
asdf-install did find them. But the lack of version checking.....anyway,  
it's working now.:)


From edi at agharta.de  Wed Apr  9 22:04:28 2008
From: edi at agharta.de (Edi Weitz)
Date: Thu, 10 Apr 2008 00:04:28 +0200
Subject: [hunchentoot-devel] problem setting up hunchentoot
In-Reply-To: <op.t9c49rc9qjq2m8@kim-laptop> (Kim Stebel's message of "Wed,
	09 Apr 2008 23:42:53 +0200")
References: <op.t9c00omuqjq2m8@kim-laptop> <uhceaoid2.fsf@agharta.de>
	<op.t9c37azuqjq2m8@kim-laptop> <u4paalnm8.fsf@agharta.de>
	<op.t9c49rc9qjq2m8@kim-laptop>
Message-ID: <uve2qk7mb.fsf@agharta.de>

On Wed, 09 Apr 2008 23:42:53 +0200, "Kim Stebel" <kimstebel at gmx.de> wrote:

> Well the ubuntu-libs are installed to the standard sbcl dir

What I see here

  http://groups.google.com/group/comp.lang.lisp/msg/33576069cdd71d23

is /usr/share/common-lisp/systems/ which is think is /not/ the
"standard SBCL dir" (whatever that is) - AFAIK it's the directory
created and used by c-l-c.

> and asdf-install did find them.

No, ASDF found them.  This is probably a bit more tricky than you
think it is and you might want to read one of the online articles
trying to explain ASDF and ASDF-INSTALL.  (Note that I'm not trying to
defend the ASDF-INSTALL design choices.  I just think you might have
wrong expectations.)


From jstraszheim at comcast.net  Wed Apr  9 22:44:35 2008
From: jstraszheim at comcast.net (Jeffrey Straszheim)
Date: Wed, 09 Apr 2008 18:44:35 -0400
Subject: [hunchentoot-devel] problem setting up hunchentoot
In-Reply-To: <op.t9c00omuqjq2m8@kim-laptop>
References: <op.t9c00omuqjq2m8@kim-laptop>
Message-ID: <47FD46D3.4050202@comcast.net>

Kim Stebel wrote:
> Hello group,
>
> I'm new to LISP and i'm trying to set up a basic "Hello World"-website
> with Hunchentoot. I'm using SBCL 1.0.6 on linux(ubuntu gutsy) and 
> installed hunchentoot
> via asdf-install. 
Hi Kim,

In addition to what others have said, your version of SBCL is rather out 
of date.  This happens a lot with the pre-packaged distributions you get 
from the various Linux sites.

I suggest you clean out your entire SBCL install, and go to the SBCL 
site and get the latest version.  I recently asked a similar question on 
the SBCL mailing list, and a fellow named Brian gave me this advice:

    I would recommend staying away from distribution packages for SBCL.
    Just download the latest binary from the web site, install it, and
    use it to compile the latest sources. It's relatively
    straightforward; the only thing that's even moderately tricky is
    building with threads. To do that, create a file named
    "customize-target-features.lisp" in the root of the SBCL sources
    containing something like:

    (lambda (list) (cons :sb-thread list))

    Then just build SBCL as usual ("sh make.sh").

It worked fine.

Once you have the latest SBCL, then reinstall ASDF-INSTALL and off you go.

You should also consider joining the SBCL mailing list (from their 
site).  You'll find them very helpful if you have a problem.

-- 
Jeffrey Straszheim
Programmer, Engineer
jstraszheim at comcast.net



From rm at seid-online.de  Thu Apr 10 11:43:35 2008
From: rm at seid-online.de (Ralf Mattes)
Date: Thu, 10 Apr 2008 13:43:35 +0200
Subject: [hunchentoot-devel] problem setting up hunchentoot
In-Reply-To: <47FD46D3.4050202@comcast.net>
References: <op.t9c00omuqjq2m8@kim-laptop>  <47FD46D3.4050202@comcast.net>
Message-ID: <1207827815.6610.9.camel@localhost.localdomain>

On Wed, 2008-04-09 at 18:44 -0400, Jeffrey Straszheim wrote:
> Kim Stebel wrote:
> > Hello group,
> >
> > I'm new to LISP and i'm trying to set up a basic "Hello World"-website
> > with Hunchentoot. I'm using SBCL 1.0.6 on linux(ubuntu gutsy) and 
> > installed hunchentoot
> > via asdf-install. 
> Hi Kim,
> 
> In addition to what others have said, your version of SBCL is rather out 
> of date.  This happens a lot with the pre-packaged distributions you get 
> from the various Linux sites.
> 
> I suggest you clean out your entire SBCL install, and go to the SBCL 
> site and get the latest version.  I recently asked a similar question on 
> the SBCL mailing list, and a fellow named Brian gave me this advice:
> 
>     I would recommend staying away from distribution packages for SBCL.
>     Just download the latest binary from the web site, install it, and
>     use it to compile the latest sources. It's relatively
>     straightforward; the only thing that's even moderately tricky is
>     building with threads. To do that, create a file named
>     "customize-target-features.lisp" in the root of the SBCL sources
>     containing something like:
> 
>     (lambda (list) (cons :sb-thread list))
> 
>     Then just build SBCL as usual ("sh make.sh").
> 
> It worked fine.

Yes - but that's incredible overkill. What problem does this actually
solve. Is there _any_ change in SBCLs between in, say, Ubuntu 7.10 and
the current CVS version that changes the behaviour of SBCL or fixes
prominent bugs? The only features I can think of are thread and unicode
support.
 
The poroblems that usually pop up in mailing lists are almost allways
related to old[1] versions of _libraries_ and the proper way to procede
here would be to nagg the package maintainer ... 
Or - even better, learn the basics of package building on your prefered
distribution and build your up-to-date local versions. I can only speak
for Debian/Ubuntu here, but I maintain local versions of most of the CL
libs I need for my projects and updating usually involves little more
than a VC update and an 'debchange -ni' to update the package version.

 And iff you feel generous you might even offer your packages to the
Debian CL folks ...

Yust my 0.02 cents

  Cheers, Ralf Mattes




From hans at huebner.org  Thu Apr 10 11:54:16 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Thu, 10 Apr 2008 13:54:16 +0200
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <uy77nnit8.fsf@agharta.de>
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<op.t9b7zf05wpmq96@smtp.xs4all.nl> <uy77nqrkx.fsf@agharta.de>
	<op.t9ck8evfwpmq96@smtp.xs4all.nl> <umyo3ozff.fsf@agharta.de>
	<1207753775.6581.7.camel@localhost.localdomain>
	<u3apvoxyx.fsf@agharta.de>
	<1207754670.6581.10.camel@localhost.localdomain>
	<uy77nnit8.fsf@agharta.de>
Message-ID: <fd2982320804100454x27864de8tf0649eea01ce04af@mail.gmail.com>

Hi Ralf,

can you come up with concrete examples of what could be configured
with Hunchentoot and mod_lisp that would not be possible in a
mod_proxy setup?  I am relatively easy to convince that keeping
mod_lisp support is a good idea, but I'd still want to know what
exactly these advantages are.

With respect to other comments:

I do like the idea of using a streams based approach to mod_lisp and
raw http support, as Arjan has suggested.  I am not sure if I will
make this change soon, though, and if I could start by removing
mod_lisp support, it would make life easier for me as well.

It would be helpful if Robert and/or Andrea could write down how
session support needs to be enhanced.

Thanks,
Hans

Thanks,
Hans

2008/4/9, Edi Weitz <edi at agharta.de>:
> On Wed, 09 Apr 2008 17:24:30 +0200, Ralf Mattes <rm at seid-online.de> wrote:
>
>  > Yes, I _thought_ that was clear. I've to admit that we are currently
>  > not using mod_lisp, just the standalone version, but it gives me a
>  > cozzy feeling to know that I _could_ get tighter integration once
>  > need arises.
>
>
> Have you actually used mod_lisp for something like that before?  I
>  asked because I couldn't really come up with a convincing case where
>  you'd get tighter Apache integration that way.  I've done quite a lot
>  of Apache hacking in my pre-Lisp life, but working with something like
>  mod_perl or writing your own modules in C is certainly different from
>  using mod_lisp.
>
> _______________________________________________
>  tbnl-devel site list
>  tbnl-devel at common-lisp.net
>  http://common-lisp.net/mailman/listinfo/tbnl-devel
>


From kimstebel at gmx.de  Thu Apr 10 12:05:00 2008
From: kimstebel at gmx.de (Kim Stebel)
Date: Thu, 10 Apr 2008 14:05:00 +0200
Subject: [hunchentoot-devel] problem setting up hunchentoot
In-Reply-To: <1207827815.6610.9.camel@localhost.localdomain>
References: <op.t9c00omuqjq2m8@kim-laptop> <47FD46D3.4050202@comcast.net>
	<1207827815.6610.9.camel@localhost.localdomain>
Message-ID: <op.t9d86me0qjq2m8@kim-laptop>

On Thu, 10 Apr 2008 13:43:35 +0200, Ralf Mattes <rm at seid-online.de> wrote:

>
> Yes - but that's incredible overkill. What problem does this actually
> solve. Is there _any_ change in SBCLs between in, say, Ubuntu 7.10 and
> the current CVS version that changes the behaviour of SBCL or fixes
> prominent bugs? The only features I can think of are thread and unicode
> support.
> The poroblems that usually pop up in mailing lists are almost allways
> related to old[1] versions of _libraries_ and the proper way to procede
> here would be to nagg the package maintainer ...
> Or - even better, learn the basics of package building on your prefered
> distribution and build your up-to-date local versions. I can only speak
> for Debian/Ubuntu here, but I maintain local versions of most of the CL
> libs I need for my projects and updating usually involves little more
> than a VC update and an 'debchange -ni' to update the package version.
>
>  And iff you feel generous you might even offer your packages to the
> Debian CL folks ...
>
> Yust my 0.02 cents
>
>   Cheers, Ralf Mattes

I absolutely agree, espescially since 1.0.6 already has support for native  
threads and unicode. And 8.04 will be out soon anyway.


From rm at seid-online.de  Thu Apr 10 12:13:24 2008
From: rm at seid-online.de (Ralf Mattes)
Date: Thu, 10 Apr 2008 14:13:24 +0200
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <fd2982320804100454x27864de8tf0649eea01ce04af@mail.gmail.com>
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<op.t9b7zf05wpmq96@smtp.xs4all.nl> <uy77nqrkx.fsf@agharta.de>
	<op.t9ck8evfwpmq96@smtp.xs4all.nl> <umyo3ozff.fsf@agharta.de>
	<1207753775.6581.7.camel@localhost.localdomain>
	<u3apvoxyx.fsf@agharta.de>
	<1207754670.6581.10.camel@localhost.localdomain>
	<uy77nnit8.fsf@agharta.de>
	<fd2982320804100454x27864de8tf0649eea01ce04af@mail.gmail.com>
Message-ID: <1207829605.6610.21.camel@localhost.localdomain>

On Thu, 2008-04-10 at 13:54 +0200, Hans H?bner wrote:
> Hi Ralf,
> 
> can you come up with concrete examples of what could be configured
> with Hunchentoot and mod_lisp that would not be possible in a
> mod_proxy setup?

As I wrote in my last mail, I'm not currently using it. I kept mod_lisp
as an option in  case I need tighter Apache integration.
I'm currently a little, erm, tight on time so I can't come up with
elaborate examples now. One usecase (which is actually something I need
to do in the next release cycle of my software): the output of the Lisp
side (xml) gets transformed by Apache output filters (xslt
transformation). All "visual" design on my customer's website is done by
XSLT stylesheets, so design changes (usually once a year :) can be done
by just rewriting the stylesheets - the content (in XML) is never
touched (as a nice side effect the content can be viewed in different
styles). The small Lisp based part of the website currently has to use
(x)html and every design change needs to be hardcoded in all TAL
templates ...

It might be possible to do this with mod_proxy as well, but I think it
would be cneptually cleaner to view the Lisp process just as yet another
content provider module.
 
>   I am relatively easy to convince that keeping
> mod_lisp support is a good idea, but I'd still want to know what
> exactly these advantages are.
> 
> With respect to other comments:
> 
> I do like the idea of using a streams based approach to mod_lisp and
> raw http support, as Arjan has suggested.  I am not sure if I will
> make this change soon, though, and if I could start by removing
> mod_lisp support, it would make life easier for me as well.

+1 from me.


> It would be helpful if Robert and/or Andrea could write down how
> session support needs to be enhanced.
> 
> Thanks,
> Hans
> 
> Thanks,
> Hans

Cheers, RalfD

and thank's for working on hunch



From kiuma72 at gmail.com  Thu Apr 10 12:14:14 2008
From: kiuma72 at gmail.com (Andrea Chiumenti)
Date: Thu, 10 Apr 2008 14:14:14 +0200
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <fd2982320804100454x27864de8tf0649eea01ce04af@mail.gmail.com>
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<op.t9b7zf05wpmq96@smtp.xs4all.nl> <uy77nqrkx.fsf@agharta.de>
	<op.t9ck8evfwpmq96@smtp.xs4all.nl> <umyo3ozff.fsf@agharta.de>
	<1207753775.6581.7.camel@localhost.localdomain>
	<u3apvoxyx.fsf@agharta.de>
	<1207754670.6581.10.camel@localhost.localdomain>
	<uy77nnit8.fsf@agharta.de>
	<fd2982320804100454x27864de8tf0649eea01ce04af@mail.gmail.com>
Message-ID: <4d3bc9370804100514y24f63ee3qe2704565bdbbc53d@mail.gmail.com>

No problem,
since I'm writing the CLAW manual, this is definitely in scope, I'll
write down the documentation of my changes to session handling for
realm support (this weekend I think, if it's not too late for you).
If you think, I can also zip the project so that you can also see how
the session things work in concrete.

kiuma

On Thu, Apr 10, 2008 at 1:54 PM, Hans H?bner <hans at huebner.org> wrote:
> Hi Ralf,
>
>  can you come up with concrete examples of what could be configured
>  with Hunchentoot and mod_lisp that would not be possible in a
>  mod_proxy setup?  I am relatively easy to convince that keeping
>  mod_lisp support is a good idea, but I'd still want to know what
>  exactly these advantages are.
>
>  With respect to other comments:
>
>  I do like the idea of using a streams based approach to mod_lisp and
>  raw http support, as Arjan has suggested.  I am not sure if I will
>  make this change soon, though, and if I could start by removing
>  mod_lisp support, it would make life easier for me as well.
>
>  It would be helpful if Robert and/or Andrea could write down how
>  session support needs to be enhanced.
>
>  Thanks,
>  Hans
>
>  Thanks,
>  Hans
>
>  2008/4/9, Edi Weitz <edi at agharta.de>:
>
>
> > On Wed, 09 Apr 2008 17:24:30 +0200, Ralf Mattes <rm at seid-online.de> wrote:
>  >
>  >  > Yes, I _thought_ that was clear. I've to admit that we are currently
>  >  > not using mod_lisp, just the standalone version, but it gives me a
>  >  > cozzy feeling to know that I _could_ get tighter integration once
>  >  > need arises.
>  >
>  >
>  > Have you actually used mod_lisp for something like that before?  I
>  >  asked because I couldn't really come up with a convincing case where
>  >  you'd get tighter Apache integration that way.  I've done quite a lot
>  >  of Apache hacking in my pre-Lisp life, but working with something like
>  >  mod_perl or writing your own modules in C is certainly different from
>  >  using mod_lisp.
>  >
>  > _______________________________________________
>  >  tbnl-devel site list
>  >  tbnl-devel at common-lisp.net
>  >  http://common-lisp.net/mailman/listinfo/tbnl-devel
>  >
>  _______________________________________________
>  tbnl-devel site list
>  tbnl-devel at common-lisp.net
>  http://common-lisp.net/mailman/listinfo/tbnl-devel
>


From css at swissjabber.ch  Thu Apr 10 12:22:15 2008
From: css at swissjabber.ch (css)
Date: Thu, 10 Apr 2008 14:22:15 +0200
Subject: [hunchentoot-devel] Hunchentoot with ECL
In-Reply-To: <u3aqjso4o.fsf@agharta.de>
References: <9e4493f70803201625r37b67d1egefed84929946b4a5@mail.gmail.com>
	<u3aqjso4o.fsf@agharta.de>
Message-ID: <9e4493f70804100522x6d7351dfted62636b12c26e4@mail.gmail.com>

Hello.

2008/3/22, Edi Weitz <edi at agharta.de>:
> I suppose there was simply no interest so far.  You're welcome to
>  provide patches for ECL.
>
>   http://weitz.de/patches.html

As I see in the other Topic of this list, ther will be some changes of
Hunchentoot soon, and as far as I read, it is really planned to use
external libraries like bordeaux-threads and usocket. This would mean,
that for the moment, it is not useful to continue porting Hunchentoot.
Is this correct?

(Has meanwhile someone a working Port?)


From edi at agharta.de  Thu Apr 10 12:29:44 2008
From: edi at agharta.de (Edi Weitz)
Date: Thu, 10 Apr 2008 14:29:44 +0200
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <1207829605.6610.21.camel@localhost.localdomain> (Ralf Mattes's
	message of "Thu, 10 Apr 2008 14:13:24 +0200")
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<op.t9b7zf05wpmq96@smtp.xs4all.nl> <uy77nqrkx.fsf@agharta.de>
	<op.t9ck8evfwpmq96@smtp.xs4all.nl> <umyo3ozff.fsf@agharta.de>
	<1207753775.6581.7.camel@localhost.localdomain>
	<u3apvoxyx.fsf@agharta.de>
	<1207754670.6581.10.camel@localhost.localdomain>
	<uy77nnit8.fsf@agharta.de>
	<fd2982320804100454x27864de8tf0649eea01ce04af@mail.gmail.com>
	<1207829605.6610.21.camel@localhost.localdomain>
Message-ID: <uskxtj3k7.fsf@agharta.de>

On Thu, 10 Apr 2008 14:13:24 +0200, Ralf Mattes <rm at seid-online.de> wrote:

> As I wrote in my last mail, I'm not currently using it. I kept
> mod_lisp as an option in case I need tighter Apache integration.
> I'm currently a little, erm, tight on time so I can't come up with
> elaborate examples now. One usecase (which is actually something I
> need to do in the next release cycle of my software): the output of
> the Lisp side (xml) gets transformed by Apache output filters (xslt
> transformation). All "visual" design on my customer's website is
> done by XSLT stylesheets, so design changes (usually once a year :)
> can be done by just rewriting the stylesheets - the content (in XML)
> is never touched (as a nice side effect the content can be viewed in
> different styles). The small Lisp based part of the website
> currently has to use (x)html and every design change needs to be
> hardcoded in all TAL templates ...
>
> It might be possible to do this with mod_proxy as well, but I think
> it would be cneptually cleaner to view the Lisp process just as yet
> another content provider module.

I haven't worked with Apache 2.x filters yet, so I can't comment on
this example.  (But I think you're right and it's a reasonable
example.)  Filters were about the only thing that came to mind when I
tried to come up with a reason to use mod_lisp because the standard
(1.x) way of writing and combining modules as described in the nice
eagle book doesn't really fit with how mod_lisp works.

So, yes, your case might be a good reason to use mod_lisp.  Whether it
is a good reason to have mod_lisp support in Hunchentoot I'm not so
sure.  Speaking of being conceptually clean, Hunchentoot has evolved
over the years and now is (or aims to be) a fully-fledged stand-alone
Lisp web server.  90% of its code base is probably totally useless if
you're just trying to write a content provider module to hook into
Apache.  Wouldn't it make more sense to use something like cl-modlisp
for this?


From edi at agharta.de  Thu Apr 10 12:32:12 2008
From: edi at agharta.de (Edi Weitz)
Date: Thu, 10 Apr 2008 14:32:12 +0200
Subject: [hunchentoot-devel] Hunchentoot with ECL
In-Reply-To: <9e4493f70804100522x6d7351dfted62636b12c26e4@mail.gmail.com>
	(css@swissjabber.ch's
	message of "Thu, 10 Apr 2008 14:22:15 +0200")
References: <9e4493f70803201625r37b67d1egefed84929946b4a5@mail.gmail.com>
	<u3aqjso4o.fsf@agharta.de>
	<9e4493f70804100522x6d7351dfted62636b12c26e4@mail.gmail.com>
Message-ID: <uod8hj3g3.fsf@agharta.de>

On Thu, 10 Apr 2008 14:22:15 +0200, css <css at swissjabber.ch> wrote:

> As I see in the other Topic of this list, ther will be some changes
> of Hunchentoot soon, and as far as I read, it is really planned to
> use external libraries like bordeaux-threads and usocket. This would
> mean, that for the moment, it is not useful to continue porting
> Hunchentoot.  Is this correct?

Yes, it seems Hans wants to take up all of this work, so I'm going to
eat what I said two weeks ago... :)

If you want to help with making Hunchentoot usable on ECL, you should
probably check if usocket and bordeaux-threads work correctly with
ECL (if you haven't done so already).


From css at swissjabber.ch  Thu Apr 10 12:35:34 2008
From: css at swissjabber.ch (css)
Date: Thu, 10 Apr 2008 14:35:34 +0200
Subject: [hunchentoot-devel] Hunchentoot with ECL
In-Reply-To: <uod8hj3g3.fsf@agharta.de>
References: <9e4493f70803201625r37b67d1egefed84929946b4a5@mail.gmail.com>
	<u3aqjso4o.fsf@agharta.de>
	<9e4493f70804100522x6d7351dfted62636b12c26e4@mail.gmail.com>
	<uod8hj3g3.fsf@agharta.de>
Message-ID: <9e4493f70804100535u6c0eb4d1rbee05a19abef2a9b@mail.gmail.com>

2008/4/10, Edi Weitz <edi at agharta.de>:
> Yes, it seems Hans wants to take up all of this work, so I'm going to
>  eat what I said two weeks ago... :)
>
>  If you want to help with making Hunchentoot usable on ECL, you should
>  probably check if usocket and bordeaux-threads work correctly with
>  ECL (if you haven't done so already).

According to http://common-lisp.net/project/bordeaux-threads/ and
http://common-lisp.net/project/usocket/ (and my personal "tests") it
is working. This was the reason why I suggested using it.


From rob at koberg.com  Thu Apr 10 12:59:49 2008
From: rob at koberg.com (Robert Koberg)
Date: Thu, 10 Apr 2008 08:59:49 -0400
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <1207829605.6610.21.camel@localhost.localdomain>
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<op.t9b7zf05wpmq96@smtp.xs4all.nl> <uy77nqrkx.fsf@agharta.de>
	<op.t9ck8evfwpmq96@smtp.xs4all.nl> <umyo3ozff.fsf@agharta.de>
	<1207753775.6581.7.camel@localhost.localdomain>
	<u3apvoxyx.fsf@agharta.de>
	<1207754670.6581.10.camel@localhost.localdomain>
	<uy77nnit8.fsf@agharta.de>
	<fd2982320804100454x27864de8tf0649eea01ce04af@mail.gmail.com>
	<1207829605.6610.21.camel@localhost.localdomain>
Message-ID: <1207832389.6513.39.camel@rkoberg-laptop>


On Thu, 2008-04-10 at 14:13 +0200, Ralf Mattes wrote:
> One usecase (which is actually something I need
> to do in the next release cycle of my software): the output of the Lisp
> side (xml) gets transformed by Apache output filters (xslt
> transformation). All "visual" design on my customer's website is done by
> XSLT stylesheets, so design changes (usually once a year :) can be done
> by just rewriting the stylesheets - the content (in XML) is never
> touched (as a nice side effect the content can be viewed in different
> styles). The small Lisp based part of the website currently has to use
> (x)html and every design change needs to be hardcoded in all TAL
> templates ...

mod_xslt2 seems pretty limited. From:

http://www.mod-xslt2.com/doc/manual.xml?sect=5

5.1.9  Increasing performance
<snip/>

Since mod-xslt2 is part of apache itself, a pipe is impossible to use,
unless we fork apache one more time, slowing things down.

The simplest approach has thus been used: creating a temporary file, let
other modules write the replies in there, and then parse the temporary
file. However, by using temporary files, we hit I/O performance issues.
<snip/>

plus, it is only XSL 1.0. There was someone working on an XSL processor
in lisp, but I don't think it is ready yet (forgot the name).

Java is currently the best environment if you have to deal with XSL
transformations server side. If you are using XSL 1.0 only, you could
just do the transformation on the client -- pretty much all browser now
support XSL 1.0.

best,
-Rob





From hans at huebner.org  Thu Apr 10 13:07:00 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Thu, 10 Apr 2008 15:07:00 +0200
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <1207832389.6513.39.camel@rkoberg-laptop>
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<op.t9ck8evfwpmq96@smtp.xs4all.nl> <umyo3ozff.fsf@agharta.de>
	<1207753775.6581.7.camel@localhost.localdomain>
	<u3apvoxyx.fsf@agharta.de>
	<1207754670.6581.10.camel@localhost.localdomain>
	<uy77nnit8.fsf@agharta.de>
	<fd2982320804100454x27864de8tf0649eea01ce04af@mail.gmail.com>
	<1207829605.6610.21.camel@localhost.localdomain>
	<1207832389.6513.39.camel@rkoberg-laptop>
Message-ID: <fd2982320804100607n2eeaaaf6w652b5c17387f6608@mail.gmail.com>

Thanks, all!   I think removing mod_lisp support is the right thing to
do for the moment, as there is enough other work.

-Hans

2008/4/10, Robert Koberg <rob at koberg.com>:
>
>  On Thu, 2008-04-10 at 14:13 +0200, Ralf Mattes wrote:
>  > One usecase (which is actually something I need
>  > to do in the next release cycle of my software): the output of the Lisp
>  > side (xml) gets transformed by Apache output filters (xslt
>  > transformation). All "visual" design on my customer's website is done by
>  > XSLT stylesheets, so design changes (usually once a year :) can be done
>  > by just rewriting the stylesheets - the content (in XML) is never
>  > touched (as a nice side effect the content can be viewed in different
>  > styles). The small Lisp based part of the website currently has to use
>  > (x)html and every design change needs to be hardcoded in all TAL
>  > templates ...
>
>
> mod_xslt2 seems pretty limited. From:
>
>  http://www.mod-xslt2.com/doc/manual.xml?sect=5
>
>  5.1.9  Increasing performance
>  <snip/>
>
>  Since mod-xslt2 is part of apache itself, a pipe is impossible to use,
>  unless we fork apache one more time, slowing things down.
>
>  The simplest approach has thus been used: creating a temporary file, let
>  other modules write the replies in there, and then parse the temporary
>  file. However, by using temporary files, we hit I/O performance issues.
>  <snip/>
>
>  plus, it is only XSL 1.0. There was someone working on an XSL processor
>  in lisp, but I don't think it is ready yet (forgot the name).
>
>  Java is currently the best environment if you have to deal with XSL
>  transformations server side. If you are using XSL 1.0 only, you could
>  just do the transformation on the client -- pretty much all browser now
>  support XSL 1.0.
>
>  best,
>  -Rob
>
>
>
>
>  _______________________________________________
>  tbnl-devel site list
>  tbnl-devel at common-lisp.net
>  http://common-lisp.net/mailman/listinfo/tbnl-devel
>


From edi at agharta.de  Thu Apr 10 13:19:59 2008
From: edi at agharta.de (Edi Weitz)
Date: Thu, 10 Apr 2008 15:19:59 +0200
Subject: [hunchentoot-devel] Re: hunchentoot build error on ccl (with new
	version, via asdf)
In-Reply-To: <512044650804100615x62b3c14fxf998f251ddec66e6@mail.gmail.com>
	(Michael Kohout's message of "Thu, 10 Apr 2008 08:15:53 -0500")
References: <512044650804100615x62b3c14fxf998f251ddec66e6@mail.gmail.com>
Message-ID: <uskxtzw1s.fsf@agharta.de>

On Thu, 10 Apr 2008 08:15:53 -0500, "Michael Kohout" <mwkohout at gmail.com> wrote:

> I'm a bit of a noob, so no patchfile but I noticed this error when I
> tried to build this morning:
>
> ? (asdf-install:install 'hunchentoot)
> Install where?
> 1) System-wide install:
>    System in /usr/local/asdf-install/site-systems/
>    Files in /usr/local/asdf-install/site/
> 2) Personal installation:
>    System in /Users/development/.asdf-install-dir/systems/
>    Files in /Users/development/.asdf-install-dir/site/
> 0) Abort installation.
>  --> 2
> ;;; ASDF-INSTALL: Downloading 129311 bytes from
> http://weitz.de/files/hunchentoot.tar.gz to
> /Users/development/asdf-install-0.asdf-install-tmp ...
> ;;; ASDF-INSTALL: Installing HUNCHENTOOT in
> /Users/development/.asdf-install-dir/site/,
> /Users/development/.asdf-install-dir/systems/
> "ln -s
> \"/Users/development/.asdf-install-dir/site/hunchentoot-0.15.6/hunchentoot-test.asd\"
> \"/Users/development/.asdf-install-dir/systems/hunchentoot-test.asd\""
> ;;; ASDF-INSTALL: Found system definition:
> /Users/development/.asdf-install-dir/site/hunchentoot-0.15.6/hunchentoot-test.asd
> "ln -s
> \"/Users/development/.asdf-install-dir/site/hunchentoot-0.15.6/hunchentoot.asd\"
> \"/Users/development/.asdf-install-dir/systems/hunchentoot.asd\""
> ;;; ASDF-INSTALL: Found system definition:
> /Users/development/.asdf-install-dir/site/hunchentoot-0.15.6/hunchentoot.asd
> ;;; ASDF-INSTALL: Loading system ASDF-INSTALL::HUNCHENTOOT via ASDF.
> ; loading system definition from
> /Users/development/.asdf-install-dir/site/hunchentoot-0.15.6/hunchentoot.asd
> into #<Package "ASDF0">
> ; registering #<SYSTEM :HUNCHENTOOT #x300041AAD8FD> as HUNCHENTOOT
> ;;; ASDF-INSTALL: Downloading package URL-REWRITE, required by hunchentoot
>
> ;;; ASDF-INSTALL: Downloading 13123 bytes from
> http://weitz.de/files/url-rewrite.tar.gz to
> /Users/development/asdf-install-1.asdf-install-tmp ...
> ;;; ASDF-INSTALL: Installing url-rewrite in
> /Users/development/.asdf-install-dir/site/,
> /Users/development/.asdf-install-dir/systems/
> "ln -s
> \"/Users/development/.asdf-install-dir/site/url-rewrite-0.1.1/url-rewrite.asd\"
> \"/Users/development/.asdf-install-dir/systems/url-rewrite.asd\""
> ;;; ASDF-INSTALL: Found system definition:
> /Users/development/.asdf-install-dir/site/url-rewrite-0.1.1/url-rewrite.asd
> "ln -s
> \"/Users/development/.asdf-install-dir/site/url-rewrite-0.1.1/url-rewrite.system\"
> \"/Users/development/.asdf-install-dir/systems/url-rewrite.system\""
> ;;; ASDF-INSTALL: Found system definition:
> /Users/development/.asdf-install-dir/site/url-rewrite-0.1.1/url-rewrite.system
> ;;; ASDF-INSTALL: Loading system ASDF-INSTALL::|url-rewrite| via ASDF.
> ; loading system definition from
> /Users/development/.asdf-install-dir/site/url-rewrite-0.1.1/url-rewrite.asd
> into #<Package "ASDF0">
> ; registering #<SYSTEM :URL-REWRITE #x300041B0201D> as URL-REWRITE
> ;;; ASDF-INSTALL: Loading system ASDF-INSTALL::HUNCHENTOOT via ASDF.
> ;;; ASDF-INSTALL: Downloading package RFC2388, required by hunchentoot
>
> ;;; ASDF-INSTALL: Downloading 6177 bytes from
> http://common-lisp.net/project/rfc2388/rfc2388_latest.tar.gz to
> /Users/development/asdf-install-2.asdf-install-tmp ...
> ;;; ASDF-INSTALL: Installing rfc2388 in
> /Users/development/.asdf-install-dir/site/,
> /Users/development/.asdf-install-dir/systems/
> "ln -s \"/Users/development/.asdf-install-dir/site/rfc2388/rfc2388.asd\"
> \"/Users/development/.asdf-install-dir/systems/rfc2388.asd\""
> ;;; ASDF-INSTALL: Found system definition:
> /Users/development/.asdf-install-dir/site/rfc2388/rfc2388.asd
> ;;; ASDF-INSTALL: Loading system ASDF-INSTALL::|rfc2388| via ASDF.
> ; loading system definition from
> /Users/development/.asdf-install-dir/site/rfc2388/rfc2388.asd into #<Package
> "ASDF0">
> ; registering #<SYSTEM :RFC2388 #x300041A7A43D> as RFC2388
> ;;; ASDF-INSTALL: Loading system ASDF-INSTALL::HUNCHENTOOT via ASDF.
> ;;; ASDF-INSTALL: Downloading package MD5, required by hunchentoot
>
> ;;; ASDF-INSTALL: Downloading 9030 bytes from
> http://files.b9.com/md5/md5-1.8.5.tar.gz to
> /Users/development/asdf-install-3.asdf-install-tmp ...
> ;;; ASDF-INSTALL: Installing md5 in
> /Users/development/.asdf-install-dir/site/,
> /Users/development/.asdf-install-dir/systems/
> "ln -s \"/Users/development/.asdf-install-dir/site/md5-1.8.5/md5.asd\"
> \"/Users/development/.asdf-install-dir/systems/md5.asd\""
> ;;; ASDF-INSTALL: Found system definition:
> /Users/development/.asdf-install-dir/site/md5-1.8.5/md5.asd
> ;;; ASDF-INSTALL: Loading system ASDF-INSTALL::|md5| via ASDF.
> ; loading system definition from
> /Users/development/.asdf-install-dir/site/md5-1.8.5/md5.asd into #<Package
> "ASDF0">
> ; registering #<SYSTEM MD5 #x300041B3DCBD> as MD5
> ;;; ASDF-INSTALL: Loading system ASDF-INSTALL::HUNCHENTOOT via ASDF.
> ;;; ASDF-INSTALL: Downloading package CL-PPCRE, required by hunchentoot
>
> ;;; ASDF-INSTALL: Downloading 171687 bytes from
> http://weitz.de/files/cl-ppcre.tar.gz to
> /Users/development/asdf-install-4.asdf-install-tmp ...
> ;;; ASDF-INSTALL: Installing cl-ppcre in
> /Users/development/.asdf-install-dir/site/,
> /Users/development/.asdf-install-dir/systems/
> "ln -s
> \"/Users/development/.asdf-install-dir/site/cl-ppcre-1.3.2/cl-ppcre-test.asd\"
> \"/Users/development/.asdf-install-dir/systems/cl-ppcre-test.asd\""
> ;;; ASDF-INSTALL: Found system definition:
> /Users/development/.asdf-install-dir/site/cl-ppcre-1.3.2/cl-ppcre-test.asd
> "ln -s
> \"/Users/development/.asdf-install-dir/site/cl-ppcre-1.3.2/cl-ppcre.asd\"
> \"/Users/development/.asdf-install-dir/systems/cl-ppcre.asd\""
> ;;; ASDF-INSTALL: Found system definition:
> /Users/development/.asdf-install-dir/site/cl-ppcre-1.3.2/cl-ppcre.asd
> "ln -s
> \"/Users/development/.asdf-install-dir/site/cl-ppcre-1.3.2/cl-ppcre-test.system\"
> \"/Users/development/.asdf-install-dir/systems/cl-ppcre-test.system\""
> ;;; ASDF-INSTALL: Found system definition:
> /Users/development/.asdf-install-dir/site/cl-ppcre-1.3.2/cl-ppcre-test.system
> "ln -s
> \"/Users/development/.asdf-install-dir/site/cl-ppcre-1.3.2/cl-ppcre.system\"
> \"/Users/development/.asdf-install-dir/systems/cl-ppcre.system\""
> ;;; ASDF-INSTALL: Found system definition:
> /Users/development/.asdf-install-dir/site/cl-ppcre-1.3.2/cl-ppcre.system
> ;;; ASDF-INSTALL: Loading system ASDF-INSTALL::|cl-ppcre| via ASDF.
> ; loading system definition from
> /Users/development/.asdf-install-dir/site/cl-ppcre-1.3.2/cl-ppcre.asd into
> #<Package "ASDF0">
> ; registering #<SYSTEM :CL-PPCRE #x300041B1888D> as CL-PPCRE
> ;;; ASDF-INSTALL: Loading system ASDF-INSTALL::HUNCHENTOOT via ASDF.
> ;;; ASDF-INSTALL: Downloading package CL-FAD, required by hunchentoot
>
> ;;; ASDF-INSTALL: Downloading 11388 bytes from
> http://weitz.de/files/cl-fad.tar.gz to
> /Users/development/asdf-install-5.asdf-install-tmp ...
> ;;; ASDF-INSTALL: Installing cl-fad in
> /Users/development/.asdf-install-dir/site/,
> /Users/development/.asdf-install-dir/systems/
> "ln -s \"/Users/development/.asdf-install-dir/site/cl-fad-0.6.2/cl-fad.asd\"
> \"/Users/development/.asdf-install-dir/systems/cl-fad.asd\""
> ;;; ASDF-INSTALL: Found system definition:
> /Users/development/.asdf-install-dir/site/cl-fad-0.6.2/cl-fad.asd
> "ln -s
> \"/Users/development/.asdf-install-dir/site/cl-fad-0.6.2/cl-fad.system\"
> \"/Users/development/.asdf-install-dir/systems/cl-fad.system\""
> ;;; ASDF-INSTALL: Found system definition:
> /Users/development/.asdf-install-dir/site/cl-fad-0.6.2/cl-fad.system
> ;;; ASDF-INSTALL: Loading system ASDF-INSTALL::|cl-fad| via ASDF.
> ; loading system definition from
> /Users/development/.asdf-install-dir/site/cl-fad-0.6.2/cl-fad.asd into
> #<Package "ASDF0">
> ; registering #<SYSTEM #:CL-FAD #x300041C75EDD> as CL-FAD
> ;;; ASDF-INSTALL: Loading system ASDF-INSTALL::HUNCHENTOOT via ASDF.
> ;;; ASDF-INSTALL: Downloading package CL-BASE64, required by hunchentoot
>
> ;;; ASDF-INSTALL: Downloading 6245 bytes from
> http://files.b9.com/cl-base64/cl-base64-latest.tar.gz to
> /Users/development/asdf-install-6.asdf-install-tmp ...
> ;;; ASDF-INSTALL: Installing cl-base64 in
> /Users/development/.asdf-install-dir/site/,
> /Users/development/.asdf-install-dir/systems/
> "ln -s
> \"/Users/development/.asdf-install-dir/site/cl-base64-3.3.2/cl-base64.asd\"
> \"/Users/development/.asdf-install-dir/systems/cl-base64.asd\""
> ;;; ASDF-INSTALL: Found system definition:
> /Users/development/.asdf-install-dir/site/cl-base64-3.3.2/cl-base64.asd
> ;;; ASDF-INSTALL: Loading system ASDF-INSTALL::|cl-base64| via ASDF.
> ; loading system definition from
> /Users/development/.asdf-install-dir/site/cl-base64-3.3.2/cl-base64.asd into
> #<Package "ASDF0">
> ; registering #<SYSTEM CL-BASE64 #x300041BC54BD> as CL-BASE64
> ; registering #<SYSTEM CL-BASE64-TESTS #x300041C2BF7D> as CL-BASE64-TESTS
> ;;; ASDF-INSTALL: Loading system ASDF-INSTALL::HUNCHENTOOT via ASDF.
> ;;; ASDF-INSTALL: Downloading package CHUNGA, required by hunchentoot
>
> ;;; ASDF-INSTALL: Downloading 16132 bytes from
> http://weitz.de/files/chunga.tar.gz to
> /Users/development/asdf-install-7.asdf-install-tmp ...
> ;;; ASDF-INSTALL: Installing chunga in
> /Users/development/.asdf-install-dir/site/,
> /Users/development/.asdf-install-dir/systems/
> "ln -s \"/Users/development/.asdf-install-dir/site/chunga-0.4.1/chunga.asd\"
> \"/Users/development/.asdf-install-dir/systems/chunga.asd\""
> ;;; ASDF-INSTALL: Found system definition:
> /Users/development/.asdf-install-dir/site/chunga-0.4.1/chunga.asd
> ;;; ASDF-INSTALL: Loading system ASDF-INSTALL::|chunga| via ASDF.
> ; loading system definition from
> /Users/development/.asdf-install-dir/site/chunga-0.4.1/chunga.asd into
> #<Package "ASDF0">
> ; registering #<SYSTEM :CHUNGA #x300041D1515D> as CHUNGA
> ;;; ASDF-INSTALL: Downloading package FLEXI-STREAMS, required by chunga
>
> ;;; ASDF-INSTALL: Downloading 123404 bytes from
> http://weitz.de/files/flexi-streams.tar.gz to
> /Users/development/asdf-install-8.asdf-install-tmp ...
> ;;; ASDF-INSTALL: Installing flexi-streams in
> /Users/development/.asdf-install-dir/site/,
> /Users/development/.asdf-install-dir/systems/
> "ln -s
> \"/Users/development/.asdf-install-dir/site/flexi-streams-0.14.0/flexi-streams.asd\"
> \"/Users/development/.asdf-install-dir/systems/flexi-streams.asd\""
> ;;; ASDF-INSTALL: Found system definition:
> /Users/development/.asdf-install-dir/site/flexi-streams-0.14.0/flexi-streams.asd
> ;;; ASDF-INSTALL: Loading system ASDF-INSTALL::|flexi-streams| via ASDF.
> ; loading system definition from
> /Users/development/.asdf-install-dir/site/flexi-streams-0.14.0/flexi-streams.asd
> into #<Package "ASDF0">
> ; registering #<SYSTEM :FLEXI-STREAMS #x300041C9FD0D> as FLEXI-STREAMS
> ; registering #<SYSTEM :FLEXI-STREAMS-TEST #x300041C8A61D> as
> FLEXI-STREAMS-TEST
> ;;; ASDF-INSTALL: Downloading package TRIVIAL-GRAY-STREAMS, required by
> flexi-streams
>
> ;;; ASDF-INSTALL: Downloading 3095 bytes from
> http://common-lisp.net/project/cl-plus-ssl/download/trivial-gray-streams.tar.gzto
> /Users/development/asdf-install-9.asdf-install-tmp ...
> ;;; ASDF-INSTALL: Installing trivial-gray-streams in
> /Users/development/.asdf-install-dir/site/,
> /Users/development/.asdf-install-dir/systems/
> "ln -s
> \"/Users/development/.asdf-install-dir/site/trivial-gray-streams-2006-09-16/trivial-gray-streams.asd\"
> \"/Users/development/.asdf-install-dir/systems/trivial-gray-streams.asd\""
> ;;; ASDF-INSTALL: Found system definition:
> /Users/development/.asdf-install-dir/site/trivial-gray-streams-2006-09-16/trivial-gray-streams.asd
> ;;; ASDF-INSTALL: Loading system ASDF-INSTALL::|trivial-gray-streams| via
> ASDF.
> ; loading system definition from
> /Users/development/.asdf-install-dir/site/trivial-gray-streams-2006-09-16/trivial-gray-streams.asd
> into #<Package "ASDF0">
> ; registering #<SYSTEM :TRIVIAL-GRAY-STREAMS #x300041CC382D> as
> TRIVIAL-GRAY-STREAMS
> ;;; ASDF-INSTALL: Loading system ASDF-INSTALL::|flexi-streams| via ASDF.
> ;;; ASDF-INSTALL: Loading system ASDF-INSTALL::|chunga| via ASDF.
> ;;; ASDF-INSTALL: Loading system ASDF-INSTALL::HUNCHENTOOT via ASDF.
> Read error between positions 4121 and 4465 in
> /Users/development/.asdf-install-dir/site/hunchentoot-0.15.6/port-mcl.lisp.
>> Error: Reader error: No external symbol named "STREAM-INPUT-TIMEOUT" in
> package #<Package "CCL"> .
>> While executing: CCL::%PARSE-TOKEN, in process Listener(79).
>> Type :POP to abort, :R for a list of available restarts.
>> Type :? for other options.

Thanks for the report.  I'm forwarding this to the mailing list.
Looks like it is related to Hans' recent changes.  You'll probably
have to update your CCL.


From rm at seid-online.de  Thu Apr 10 13:35:04 2008
From: rm at seid-online.de (Ralf Mattes)
Date: Thu, 10 Apr 2008 15:35:04 +0200
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <1207832389.6513.39.camel@rkoberg-laptop>
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
	<op.t9b7zf05wpmq96@smtp.xs4all.nl> <uy77nqrkx.fsf@agharta.de>
	<op.t9ck8evfwpmq96@smtp.xs4all.nl> <umyo3ozff.fsf@agharta.de>
	<1207753775.6581.7.camel@localhost.localdomain>
	<u3apvoxyx.fsf@agharta.de>
	<1207754670.6581.10.camel@localhost.localdomain>
	<uy77nnit8.fsf@agharta.de>
	<fd2982320804100454x27864de8tf0649eea01ce04af@mail.gmail.com>
	<1207829605.6610.21.camel@localhost.localdomain>
	<1207832389.6513.39.camel@rkoberg-laptop>
Message-ID: <1207834504.6610.41.camel@localhost.localdomain>

On Thu, 2008-04-10 at 08:59 -0400, Robert Koberg wrote:
> On Thu, 2008-04-10 at 14:13 +0200, Ralf Mattes wrote:
> > One usecase (which is actually something I need
> > to do in the next release cycle of my software): the output of the Lisp
> > side (xml) gets transformed by Apache output filters (xslt
> > transformation). All "visual" design on my customer's website is done by
> > XSLT stylesheets, so design changes (usually once a year :) can be done
> > by just rewriting the stylesheets - the content (in XML) is never
> > touched (as a nice side effect the content can be viewed in different
> > styles). The small Lisp based part of the website currently has to use
> > (x)html and every design change needs to be hardcoded in all TAL
> > templates ...
> 
> mod_xslt2 seems pretty limited. From:
> 
> http://www.mod-xslt2.com/doc/manual.xml?sect=5

In case you responded to my message: did I ever mention mod-xslt2? We
use our own xslt transforming module using Daniel's excellent libxslt
(unfortunately the module is named mod_xslt, but it's actually much
older than the well known modules :)
When I hacked the first version it was meant as a joke to make fun of
the java software used back then. I can't really comment on mod-xslt2
since I only use it on a rather seldom exposed area of the website but I
don't think it's especially slow. My only critique would be that it
suffers from a severe "second implementation syndrome" - there _seems_
to be quite a lot of premature (?) optimization and feeping keaturism
IMHO. Our little module doesn't even bother to cache the compiled
stylesheet - every request reads, parses and compiles the needed
stylesheets (and boy do they overuse includes and imports :-) and the
transforms the content. So far we seldom had performance problems, even
so the site runs on stock server hardware. 
   
> 5.1.9  Increasing performance
> <snip/>
> 
> Since mod-xslt2 is part of apache itself, a pipe is impossible to use,
> unless we fork apache one more time, slowing things down.
> 
> The simplest approach has thus been used: creating a temporary file, let
> other modules write the replies in there, and then parse the temporary
> file. However, by using temporary files, we hit I/O performance issues.
> <snip/>

Where's my babelfish? 


> plus, it is only XSL 1.0. There was someone working on an XSL processor
> in lisp, but I don't think it is ready yet (forgot the name).

Yeah. Only XSLT 1. IMHO that's a feature, not a bug. XSLT 1 had a very
clear operational model (by accident, i fear, they seem to have
inherited it from the DSSSL past) that should be near and dear to us
Schemers^H^H Lispers - purely functional without assignment.
  
> Java is currently the best environment if you have to deal with XSL
> transformations server side. If you are using XSL 1.0 only, you could
> just do the transformation on the client -- pretty much all browser now
> support XSL 1.0.

Last time we tested that wasn't a convincing option since that required
the transfer of stylesheets (since the site uses a rather modular
stylesheet setup that resulted in a noticeable increase in server load).

 Cheers, RalfD
 

> best,
> -Rob
> 
> 
> 
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel



From gwking at metabang.com  Thu Apr 10 15:06:10 2008
From: gwking at metabang.com (Gary King)
Date: Thu, 10 Apr 2008 11:06:10 -0400
Subject: [hunchentoot-devel] Re: Refactoring work plan
In-Reply-To: <u8wzmohj2.fsf@agharta.de>
References: <fd2982320804090903t16361b1i9c1b664d26c3a6ee@mail.gmail.com>
	<u8wzmohj2.fsf@agharta.de>
Message-ID: <E8B23FC6-06CF-4E90-A927-CF3895CCEA20@metabang.com>

>> Also, there should be a logging API.
>
> I haven't really looked at the available logging libs yet.  Would it
> make sense to use one of those?  The current implementation certainly
> has a couple of flaws.

I suggest Nick Levines cl-log (I haven't looked too closely, but I  
have the impression that he took what is good about log5 and made it  
better...). Log5 is probably aso worth looking at.
--
Gary Warren King, metabang.com
Cell: (413) 559 8738
Fax: (206) 338-4052
gwkkwg on Skype * garethsan on AIM






From hans at huebner.org  Thu Apr 10 15:15:49 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Thu, 10 Apr 2008 17:15:49 +0200
Subject: [hunchentoot-devel] Re: Refactoring work plan
In-Reply-To: <E8B23FC6-06CF-4E90-A927-CF3895CCEA20@metabang.com>
References: <fd2982320804090903t16361b1i9c1b664d26c3a6ee@mail.gmail.com>
	<u8wzmohj2.fsf@agharta.de>
	<E8B23FC6-06CF-4E90-A927-CF3895CCEA20@metabang.com>
Message-ID: <fd2982320804100815v8bcde3ep763af9d646886ccc@mail.gmail.com>

I think I will not add a logging subsystem.  My plan is to make the
log-message function part of the official API and provide for a way to
specify the logging function so that everyone can use their own
favoured logging framework.

-Hans

2008/4/10, Gary King <gwking at metabang.com>:
> >
> > > Also, there should be a logging API.
> > >
> >
> > I haven't really looked at the available logging libs yet.  Would it
> > make sense to use one of those?  The current implementation certainly
> > has a couple of flaws.
> >
>
>  I suggest Nick Levines cl-log (I haven't looked too closely, but I have the
> impression that he took what is good about log5 and made it better...). Log5
> is probably aso worth looking at.
>  --
>  Gary Warren King, metabang.com
>  Cell: (413) 559 8738
>  Fax: (206) 338-4052
>  gwkkwg on Skype * garethsan on AIM
>
>
>
>
>


From hans at huebner.org  Thu Apr 10 16:00:11 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Thu, 10 Apr 2008 18:00:11 +0200
Subject: [hunchentoot-devel] Re: hunchentoot build error on ccl (with new
	version, via asdf)
In-Reply-To: <uskxtzw1s.fsf@agharta.de>
References: <512044650804100615x62b3c14fxf998f251ddec66e6@mail.gmail.com>
	<uskxtzw1s.fsf@agharta.de>
Message-ID: <fd2982320804100900i9722d69if8e4b34e0e398e04@mail.gmail.com>

Current CL+SSL requires CCL from the Subversion trunk - Check out
http://ccl.clozure.com/ccl-documentation.html for instructions on how
to check out the trunk version of CCL from the repository.  The 1.2
release is upcoming, but not yet done.

-Hans


From foobarpublic at yahoo.com.au  Fri Apr 11 08:26:17 2008
From: foobarpublic at yahoo.com.au (Raffaele)
Date: Fri, 11 Apr 2008 01:26:17 -0700 (PDT)
Subject: [hunchentoot-devel] Re: hunchentoot build error on ccl (with new
	version, via asdf)
Message-ID: <202863.8866.qm@web56712.mail.re3.yahoo.com>

I have the same problem using the latest CCL 1.1-r8836S (DarwinPPC32)


Read error between positions 4121 and 4465 in /usr/local/lisp/site/hunchentoot-0.15.6/port-mcl.lisp.
> Error: Reader error: No external symbol named "STREAM-INPUT-TIMEOUT" in package #<Package "CCL"> .


I had a look at port-mcl.lisp and it's expecting the symbol STREAM-INPUT-TIMEOUT in the CCL package.  I'm
assuming that this symbol is defined in release 1.2?


Prior to the upgrade Hunchentoot 0.15.1 was working - except for below!


The reason I decided to upgrade was because Hunchentoot would not return my formatted string
as the response body after setf'ing return-code to +http-created+.   If I did not set the return code (even
to the default +http-ok+) Hunchentoot would return my string to the client.  This was in response to a POST
request.




----- Original Message ----
From: Hans H?bner <hans at huebner.org>
To: General interest list for Hunchentoot and CL-WEBDAV <tbnl-devel at common-lisp.net>
Sent: Friday, 11 April, 2008 2:00:11 AM
Subject: Re: [hunchentoot-devel] Re: hunchentoot build error on ccl (with new version, via asdf)

Current CL+SSL requires CCL from the Subversion trunk - Check out
http://ccl.clozure.com/ccl-documentation.html for instructions on how
to check out the trunk version of CCL from the repository.  The 1.2
release is upcoming, but not yet done.

-Hans
_______________________________________________
tbnl-devel site list
tbnl-devel at common-lisp.net
http://common-lisp.net/mailman/listinfo/tbnl-devel







      Get the name you always wanted with the new y7mail email address.
www.yahoo7.com.au/y7mail

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20080411/a4471993/attachment.html>

From hans at huebner.org  Fri Apr 11 08:33:21 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Fri, 11 Apr 2008 10:33:21 +0200
Subject: [hunchentoot-devel] Re: hunchentoot build error on ccl (with new
	version, via asdf)
In-Reply-To: <202863.8866.qm@web56712.mail.re3.yahoo.com>
References: <202863.8866.qm@web56712.mail.re3.yahoo.com>
Message-ID: <fd2982320804110133j33eaf69ak9f8319f9d36c3cbd@mail.gmail.com>

2008/4/11, Raffaele <foobarpublic at yahoo.com.au>:
>
> I have the same problem using the latest CCL 1.1-r8836S (DarwinPPC32)
>
> Read error between positions 4121 and 4465 in
> /usr/local/lisp/site/hunchentoot-0.15.6/port-mcl.lisp.
>
> > Error: Reader error: No external symbol named "STREAM-INPUT-TIMEOUT" in
> package #<Package "CCL"> .
>
> I had a look at port-mcl.lisp and it's expecting the symbol
> STREAM-INPUT-TIMEOUT in the CCL package.  I'm
> assuming that this symbol is defined in release 1.2?

Correct.  There has been a recent update to CL+SSL that works only
with fairly recent CCLs.  If upgrading CCL is possible for you, it is
the best option.  I am using CCL from trunk on a PowerBook G4 running
Tiger and it works great for me.

-Hans

>
> Prior to the upgrade Hunchentoot 0.15.1 was working - except for below!
>
>
> The reason I decided to upgrade was because Hunchentoot would not return my
> formatted string
> as the response body after setf'ing return-code to +http-created+.   If I
> did not set the return code (even
> to the default +http-ok+) Hunchentoot would return my string to the client.
> This was in response to a POST
> request.
>
>
> ----- Original Message ----
> From: Hans H?bner <hans at huebner.org>
> To: General interest list for Hunchentoot and CL-WEBDAV
> <tbnl-devel at common-lisp.net>
> Sent: Friday, 11 April, 2008 2:00:11 AM
> Subject: Re: [hunchentoot-devel] Re: hunchentoot build error on ccl (with
> new version, via asdf)
>
> Current CL+SSL requires CCL from the Subversion trunk - Check out
> http://ccl.clozure.com/ccl-documentation.html for
> instructions on how
> to check out the trunk version of CCL from the repository.  The 1.2
> release is upcoming, but not yet done.
>
> -Hans
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
>
>  ________________________________
>  Get the name you always wanted with the new y7mail email address.
> _______________________________________________
>  tbnl-devel site list
>  tbnl-devel at common-lisp.net
>  http://common-lisp.net/mailman/listinfo/tbnl-devel
>


From edi at agharta.de  Fri Apr 11 08:36:51 2008
From: edi at agharta.de (Edi Weitz)
Date: Fri, 11 Apr 2008 10:36:51 +0200
Subject: [hunchentoot-devel] Re: hunchentoot build error on ccl (with
	new version, via asdf)
In-Reply-To: <202863.8866.qm@web56712.mail.re3.yahoo.com> (Raffaele's
	message of "Fri, 11 Apr 2008 01:26:17 -0700 (PDT)")
References: <202863.8866.qm@web56712.mail.re3.yahoo.com>
Message-ID: <uiqyoaiu4.fsf@agharta.de>

On Fri, 11 Apr 2008 01:26:17 -0700 (PDT), Raffaele <foobarpublic at yahoo.com.au> wrote:

> The reason I decided to upgrade was because Hunchentoot would not
> return my formatted string as the response body after setf'ing
> return-code to +http-created+.  If I did not set the return code
> (even to the default +http-ok+) Hunchentoot would return my string
> to the client.  This was in response to a POST request.

See here:

  http://weitz.de/hunchentoot/#*approved-return-codes*

It is unusual to send content together with a 201 reply, but if you
want, you can do it.  RTFM... :)


From edi at agharta.de  Fri Apr 11 08:38:38 2008
From: edi at agharta.de (Edi Weitz)
Date: Fri, 11 Apr 2008 10:38:38 +0200
Subject: [hunchentoot-devel] Re: hunchentoot build error on ccl (with
	new version, via asdf)
In-Reply-To: <fd2982320804110133j33eaf69ak9f8319f9d36c3cbd@mail.gmail.com>
	(Hans =?iso-8859-1?q?H=FCbner's?= message of "Fri,
	11 Apr 2008 10:33:21 +0200")
References: <202863.8866.qm@web56712.mail.re3.yahoo.com>
	<fd2982320804110133j33eaf69ak9f8319f9d36c3cbd@mail.gmail.com>
Message-ID: <uej9cair5.fsf@agharta.de>

On Fri, 11 Apr 2008 10:33:21 +0200, "Hans H?bner" <hans at huebner.org> wrote:

> Correct.  There has been a recent update to CL+SSL

But the error message was in Hunchentoot's port-mcl.lisp, not in
CL+SSL.


From hans at huebner.org  Fri Apr 11 08:50:34 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Fri, 11 Apr 2008 10:50:34 +0200
Subject: [hunchentoot-devel] Re: hunchentoot build error on ccl (with new
	version, via asdf)
In-Reply-To: <uej9cair5.fsf@agharta.de>
References: <202863.8866.qm@web56712.mail.re3.yahoo.com>
	<fd2982320804110133j33eaf69ak9f8319f9d36c3cbd@mail.gmail.com>
	<uej9cair5.fsf@agharta.de>
Message-ID: <fd2982320804110150p271185e8j83b5f72cd27f31a9@mail.gmail.com>

2008/4/11, Edi Weitz <edi at agharta.de>:
> On Fri, 11 Apr 2008 10:33:21 +0200, "Hans H?bner" <hans at huebner.org> wrote:
>
>  > Correct.  There has been a recent update to CL+SSL
>
>
> But the error message was in Hunchentoot's port-mcl.lisp, not in
>  CL+SSL.

That slipped my attention, sorry.  The cure is the same, though:  Upgrade CCL.

-Hans

>
> _______________________________________________
>  tbnl-devel site list
>  tbnl-devel at common-lisp.net
>  http://common-lisp.net/mailman/listinfo/tbnl-devel
>


From foobarpublic at yahoo.com.au  Fri Apr 11 10:34:48 2008
From: foobarpublic at yahoo.com.au (Raffaele)
Date: Fri, 11 Apr 2008 03:34:48 -0700 (PDT)
Subject: [hunchentoot-devel] Re: hunchentoot build error on ccl (with new
	version, via asdf)
Message-ID: <557318.4543.qm@web56712.mail.re3.yahoo.com>

Hans, I am the same setup as yourself except I pulled CCL from the 1.1 branch as
as per instructions.  Upgrading is possible.  How is stability compared to 1.1?


Edi, Thanks!  I'll RTFM better next time.  Hunchentoot is excellent: it's been a real
joy to build a RESTful server with it :)


----- Original Message ----
From: Hans H?bner <hans at huebner.org>
To: General interest list for Hunchentoot and CL-WEBDAV <tbnl-devel at common-lisp.net>
Sent: Friday, 11 April, 2008 6:50:34 PM
Subject: Re: [hunchentoot-devel] Re: hunchentoot build error on ccl (with new version, via asdf)

2008/4/11, Edi Weitz <edi at agharta.de>:
> On Fri, 11 Apr 2008 10:33:21 +0200, "Hans H?bner" <hans at huebner.org> wrote:
>
>  > Correct.  There has been a recent update to CL+SSL
>
>
> But the error message was in Hunchentoot's port-mcl.lisp, not in
>  CL+SSL.

That slipped my attention, sorry.  The cure is the same, though:  Upgrade CCL.

-Hans

>
> _______________________________________________
>  tbnl-devel site list
>  tbnl-devel at common-lisp.net
>  http://common-lisp.net/mailman/listinfo/tbnl-devel
>
_______________________________________________
tbnl-devel site list
tbnl-devel at common-lisp.net
http://common-lisp.net/mailman/listinfo/tbnl-devel









      Get the name you always wanted with the new y7mail email address.
www.yahoo7.com.au/y7mail

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20080411/e3ef7343/attachment.html>

From hans at huebner.org  Fri Apr 11 10:43:31 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Fri, 11 Apr 2008 12:43:31 +0200
Subject: [hunchentoot-devel] Re: hunchentoot build error on ccl (with new
	version, via asdf)
In-Reply-To: <557318.4543.qm@web56712.mail.re3.yahoo.com>
References: <557318.4543.qm@web56712.mail.re3.yahoo.com>
Message-ID: <fd2982320804110343n1e9924bdl7a9affc5f1ff19be@mail.gmail.com>

2008/4/11, Raffaele <foobarpublic at yahoo.com.au>:
>
>
> Hans, I am the same setup as yourself except I pulled CCL from the 1.1
> branch as as per instructions.  Upgrading is possible.  How is stability compared to
> 1.1?

There is still quite some movement in the 1.2 branch, but I have found
the compiler to be reliable enough for regular use.  We run our
automated integration test with a fairly recent trunk version of CCL,
and usually it usually works fine.  If it does not, I found the bugs
already fixed in the trunk version, so a simple update from svn helped
me two or three times.

I know it is a pain to work with a compiler that is not fully release
tested.  Until CCL 1.2 is out, I can't really give better advice than
to live with it.

-Hans

>
> Edi, Thanks!  I'll RTFM better next time.  Hunchentoot is excellent: it's
> been a real
> joy to build a RESTful server with it :)
>
>
> ----- Original Message ----
> From: Hans H?bner <hans at huebner.org>
> To: General interest list for Hunchentoot and CL-WEBDAV
> <tbnl-devel at common-lisp.net>
> Sent: Friday, 11 April, 2008 6:50:34 PM
> Subject: Re: [hunchentoot-devel] Re: hunchentoot build error on ccl (with
> new version, via asdf)
>
> 2008/4/11, Edi Weitz <edi at agharta.de>:
> > On Fri, 11 Apr 2008 10:33:21 +0200, "Hans H?bner" <hans at huebner.org>
> wrote:
> >
> >  > Correct.  There has been a recent update to CL+SSL
> >
> >
> > But the error message was in Hunchentoot's port-mcl.lisp, not in
> >  CL+SSL.
>
> That slipped my attention, sorry.  The cure is the same, though:  Upgrade
> CCL.
>
> -Hans
>
> >
> > _______________________________________________
> >  tbnl-devel site list
> >  tbnl-devel at common-lisp.net
> >  http://common-lisp.net/mailman/listinfo/tbnl-devel
> >
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
>
>
>  ________________________________
>  Get the name you always wanted with the new y7mail email address.
> _______________________________________________
>  tbnl-devel site list
>  tbnl-devel at common-lisp.net
>  http://common-lisp.net/mailman/listinfo/tbnl-devel
>


From kiuma72 at gmail.com  Sat Apr 12 12:46:04 2008
From: kiuma72 at gmail.com (Andrea Chiumenti)
Date: Sat, 12 Apr 2008 12:46:04 +0000
Subject: [hunchentoot-devel] Sessions for realm aware Realm
Message-ID: <4d3bc9370804120546q6a3a6b98qbca788446bd8e7d6@mail.gmail.com>

Hello,
I've created a small example of how the changes I've applied to
hunchentoot manage session for realm awareness.
To keep things clear I've only used cl-who, that nearly everyone knows here.
The test comes with its usual asd file.
To run the test, just run:

CL-USER> (asdf:operate 'asdf:load-op :new-session)

CL-USER> (new-session:start-test)

and follow "http://localhost:4242/new-session/index.html" on your browser.

Try it with cookies enabled and disabled, with
*rewrite-for-session-urls* set to T and nil.

Let me know,

kiuma
-------------- next part --------------
A non-text attachment was scrubbed...
Name: new-session.tar.bz2
Type: application/x-bzip2
Size: 4578 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20080412/d871ac92/attachment.bin>

From hans at huebner.org  Sat Apr 12 13:15:04 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Sat, 12 Apr 2008 15:15:04 +0200
Subject: [hunchentoot-devel] Sessions for realm aware Realm
In-Reply-To: <4d3bc9370804120546q6a3a6b98qbca788446bd8e7d6@mail.gmail.com>
References: <4d3bc9370804120546q6a3a6b98qbca788446bd8e7d6@mail.gmail.com>
Message-ID: <fd2982320804120615n58e7cc51pc67dd9316180e66d@mail.gmail.com>

Hi Andrea,

if I understand your source code right, what you need is a realm
argument to START-SESSION that makes it possible to have multiple
sessions on one Hunchentoot server.  Correct?

Thanks,
Hans

On 4/12/08, Andrea Chiumenti <kiuma72 at gmail.com> wrote:
> Hello,
>  I've created a small example of how the changes I've applied to
>  hunchentoot manage session for realm awareness.
>  To keep things clear I've only used cl-who, that nearly everyone knows here.
>  The test comes with its usual asd file.
>  To run the test, just run:
>
>  CL-USER> (asdf:operate 'asdf:load-op :new-session)
>
>  CL-USER> (new-session:start-test)
>
>  and follow "http://localhost:4242/new-session/index.html" on your browser.
>
>  Try it with cookies enabled and disabled, with
>  *rewrite-for-session-urls* set to T and nil.
>
>  Let me know,
>
>  kiuma
>
> _______________________________________________
>  tbnl-devel site list
>  tbnl-devel at common-lisp.net
>  http://common-lisp.net/mailman/listinfo/tbnl-devel
>
>


From hans at huebner.org  Sat Apr 12 13:17:25 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Sat, 12 Apr 2008 15:17:25 +0200
Subject: [hunchentoot-devel] Sessions for realm aware Realm
In-Reply-To: <fd2982320804120615n58e7cc51pc67dd9316180e66d@mail.gmail.com>
References: <4d3bc9370804120546q6a3a6b98qbca788446bd8e7d6@mail.gmail.com>
	<fd2982320804120615n58e7cc51pc67dd9316180e66d@mail.gmail.com>
Message-ID: <fd2982320804120617s5d898482o2d46687c0aee3df9@mail.gmail.com>

On 4/12/08, Hans H?bner <hans at huebner.org> wrote:
>  if I understand your source code right, what you need is a realm
>  argument to START-SESSION that makes it possible to have multiple
>  sessions on one Hunchentoot server.  Correct?

Well, I realised that my description of the feature is not quite
right, another try:  You want to have the option to use multiple
sessions within one request, qualified by a realm argument.  Or what?
It would really help if you would describe your requirements yourself
instead of letting us guess from your example source code.

-Hans


From kiuma72 at gmail.com  Sat Apr 12 14:14:33 2008
From: kiuma72 at gmail.com (Andrea Chiumenti)
Date: Sat, 12 Apr 2008 14:14:33 +0000
Subject: [hunchentoot-devel] Sessions for realm aware Realm
In-Reply-To: <fd2982320804120617s5d898482o2d46687c0aee3df9@mail.gmail.com>
References: <4d3bc9370804120546q6a3a6b98qbca788446bd8e7d6@mail.gmail.com>
	<fd2982320804120615n58e7cc51pc67dd9316180e66d@mail.gmail.com>
	<fd2982320804120617s5d898482o2d46687c0aee3df9@mail.gmail.com>
Message-ID: <4d3bc9370804120714p1d68ea71xb0fceecb29d03f9d@mail.gmail.com>

Not completely correct.

Suppose we want to "deploy" two applications in the same hunchentoot
server instance.
First, since they are two applications, they must have their own
cookie each one.


Now we have two options:
1) let them to share the same session data, then bind the two
applications to the same realm,
2) make the two applications completely independents, then bind them
to two different realms.

So,
1 request to only 1 session
and one session may be shared or not.

kiuma




On Sat, Apr 12, 2008 at 1:17 PM, Hans H?bner <hans at huebner.org> wrote:
> On 4/12/08, Hans H?bner <hans at huebner.org> wrote:
>  >  if I understand your source code right, what you need is a realm
>  >  argument to START-SESSION that makes it possible to have multiple
>  >  sessions on one Hunchentoot server.  Correct?
>
>  Well, I realised that my description of the feature is not quite
>  right, another try:  You want to have the option to use multiple
>  sessions within one request, qualified by a realm argument.  Or what?
>  It would really help if you would describe your requirements yourself
>  instead of letting us guess from your example source code.
>
>  -Hans
>
>
> _______________________________________________
>  tbnl-devel site list
>  tbnl-devel at common-lisp.net
>  http://common-lisp.net/mailman/listinfo/tbnl-devel
>


From hans at huebner.org  Sat Apr 12 18:28:11 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Sat, 12 Apr 2008 20:28:11 +0200
Subject: [hunchentoot-devel] Sessions for realm aware Realm
In-Reply-To: <4d3bc9370804120714p1d68ea71xb0fceecb29d03f9d@mail.gmail.com>
References: <4d3bc9370804120546q6a3a6b98qbca788446bd8e7d6@mail.gmail.com>
	<fd2982320804120615n58e7cc51pc67dd9316180e66d@mail.gmail.com>
	<fd2982320804120617s5d898482o2d46687c0aee3df9@mail.gmail.com>
	<4d3bc9370804120714p1d68ea71xb0fceecb29d03f9d@mail.gmail.com>
Message-ID: <fd2982320804121128k22efbd92h261e38a3c9f0640f@mail.gmail.com>

Can we get away with extending START-SESSION by a realm argument that
is added to or used instead of the *SESSION-COOKIE-NAME* to determine
the cookie name or session id parameter?

-Hans

On 4/12/08, Andrea Chiumenti <kiuma72 at gmail.com> wrote:
> Not completely correct.
>
>  Suppose we want to "deploy" two applications in the same hunchentoot
>  server instance.
>  First, since they are two applications, they must have their own
>  cookie each one.
>
>
>  Now we have two options:
>  1) let them to share the same session data, then bind the two
>  applications to the same realm,
>  2) make the two applications completely independents, then bind them
>  to two different realms.
>
>  So,
>  1 request to only 1 session
>  and one session may be shared or not.
>
>  kiuma
>
>
>
>
>
>  On Sat, Apr 12, 2008 at 1:17 PM, Hans H?bner <hans at huebner.org> wrote:
>  > On 4/12/08, Hans H?bner <hans at huebner.org> wrote:
>  >  >  if I understand your source code right, what you need is a realm
>  >  >  argument to START-SESSION that makes it possible to have multiple
>  >  >  sessions on one Hunchentoot server.  Correct?
>  >
>  >  Well, I realised that my description of the feature is not quite
>  >  right, another try:  You want to have the option to use multiple
>  >  sessions within one request, qualified by a realm argument.  Or what?
>  >  It would really help if you would describe your requirements yourself
>  >  instead of letting us guess from your example source code.
>  >
>  >  -Hans
>  >
>  >
>
> > _______________________________________________
>  >  tbnl-devel site list
>  >  tbnl-devel at common-lisp.net
>  >  http://common-lisp.net/mailman/listinfo/tbnl-devel
>  >
>  _______________________________________________
>  tbnl-devel site list
>  tbnl-devel at common-lisp.net
>  http://common-lisp.net/mailman/listinfo/tbnl-devel
>


From ch-tbnl at bobobeach.com  Sat Apr 12 18:49:42 2008
From: ch-tbnl at bobobeach.com (Cyrus Harmon)
Date: Sat, 12 Apr 2008 11:49:42 -0700
Subject: [hunchentoot-devel] Re: hunchentoot authorization
In-Reply-To: <u8wzkbzzk.fsf@agharta.de>
References: <646F5ECD-F5B7-41A9-8162-6D565E122A14@cyrusharmon.org>
	<u8wzkbzzk.fsf@agharta.de>
Message-ID: <DA33FF0D-C2C0-4617-8952-93120A8B9E9A@bobobeach.com>


I emailed Edi a week or so with some half-baked ideas about  
authorization/authentication and hunchentoot. He suggested continuing  
this discussion on the list, so I'm forwarding his initial comments  
below. For some background here, my initial approach to authorization  
with hunchentoot can be found at:

http://git.cyrusharmon.org/cgi-bin/gitweb.cgi?p=hunchentoot-auth.git

quoting my initial message, (some of) the motivation for this is to  
have:

  * HTML-based login, rather than the standard browser authentication
    dialog box
  * some notion of users/groups/realms
  * an easy way to serve content to:
    ** non-authenticated users
    ** authenticated but not necessarily authorized for this page users
    ** authenticated and authorized users

Edi's questions and some answers are

> 1. How do you enable users of hunchentoot-auth to use their own design
>   for the login and rejection pages?

Yes, this is one of the main issues with the current design. Right now  
this is handled through the authorized-page macro. It allows for users  
(developers) to pass in a :login-page-function which should handle that.

> 2. Where do you end up if the login was successful?  Is it the same
>   page for all users?

authorized-page is a macro that wraps each authorized page, so you end  
up on the selected page. not the most elegant way to do things. I'd  
like to remove the use of the macro here and tap into ht's dispatch  
machinery to do this more elegantly.

> 3. Do you have a mechanism where, if I enter the URL of a page which
>   needs authorization, I first have to log in but will then be
>   redirected to the page I wanted to go to in the first place?


yes, that's what the authorized-page macro does. again, there's  
probably a better approach.

> This also raises the question how these are stored.  Maybe provide
> hooks or a backend API so that one can use an existing database and/or
> combine with your own user class?  (I.e. the USER class of
> hunchentoot-auth should probably be prepared to be a mixin.)


For ht-auth, this is stored in the realm class. It would certainly be  
simple enough to have a generic realm class along with a simple-realm  
or some such that has the current (admittedly trivial) functionality  
of storing the users/password-hashes in a local file.

Further thoughts/comments on authorization and hunchentoot from the  
list?

thanks,

Cyrus



On Apr 11, 2008, at 12:41 AM, Edi Weitz wrote:

> Hi Cyrus,
>
> I've looked at this (a bit!) now and I'm adding my thoughts about the
> issue below.  Sorry for the delay.
>
> On Thu, 3 Apr 2008 11:52:32 -0700, Cyrus Harmon  
> <cyrus at cyrusharmon.org> wrote:
>
>> The issue is authentication. Hunchentoot kindly provides some basic
>> services, but I'd like a more full-featured authentication mechanism
>> with features like:
>>
>>  * HTML-based login, rather than the standard browser authentication
>>    dialog box
>>  * some notion of users/groups/realms
>>  * an easy way to serve content to:
>>    ** non-authenticated users
>>    ** authenticated but not necessarily authorized for this page  
>> users
>>    ** authenticated and authorized users
>
> I agree that all of this is usually needed/wanted in a "modern" web
> application and I've often implemented at least parts of this myself.
>
> Possible problems that I'm seeing here (if you want a flexible and
> general solution):
>
> 1. How do you enable users of hunchentoot-auth to use their own design
>   for the login and rejection pages?
>
> 2. Where do you end up if the login was successful?  Is it the same
>   page for all users?
>
> 3. Do you have a mechanism where, if I enter the URL of a page which
>   needs authorization, I first have to log in but will then be
>   redirected to the page I wanted to go to in the first place?
>
>>  * an administrative UI for managing users/groups/realms
>
> This also raises the question how these are stored.  Maybe provide
> hooks or a backend API so that one can use an existing database and/or
> combine with your own user class?  (I.e. the USER class of
> hunchentoot-auth should probably be prepared to be a mixin.)
>
>>  * a UI for requesting new accounts, possibly with some sort of
>>    admin step hook or email based confirmation of accounts
>
> Yep.
>
> Would it make sense to continue this discussion on the mailing list?
>
> Cheers,
> Edi.



From bryan.emrys at gmail.com  Sat Apr 12 22:16:59 2008
From: bryan.emrys at gmail.com (Bryan Emrys)
Date: Sat, 12 Apr 2008 15:16:59 -0700
Subject: [hunchentoot-devel] Re: hunchentoot authorization
In-Reply-To: <DA33FF0D-C2C0-4617-8952-93120A8B9E9A@bobobeach.com>
References: <646F5ECD-F5B7-41A9-8162-6D565E122A14@cyrusharmon.org>
	<u8wzkbzzk.fsf@agharta.de>
	<DA33FF0D-C2C0-4617-8952-93120A8B9E9A@bobobeach.com>
Message-ID: <200804121517.00037.bryan.emrys@gmail.com>

Is this a server function or an app function? By the time you start rolling out full ACL capability, aren't you pretty far removed from the server?

On the app I'm maintaining (non-lisp), data can come in from several sources with different licenses. Some of the data sources give us site-wide licenses, others are limited to certain specific individuals. So it isn't just a question of is the user authorized to see a certain area of the site (and, if so, do they have read/add/edit capabilities within that area), but data searches need to see if this chunk of data has license restrictions which further limit the read/add/edit capability for that specific piece of data. 

So a typical internal user will say - log me in and the app knows that this user is limited to area 123.
The user asks "tell me everything we know about  in XYZ in Thailand"
The app then looks for everything in the system about XYZ in Thailand which this user is allowed to view and builds a page from that data.

Since "pages" are built on the fly from the database search results, there is no such thing as an "authorized page". A different user who may be on more or fewer or just different data source licenses would see a completely "different" page. (Different in the sense that the data on the page would be different - the url would be exactly the same.) The user could even see a page with no data, just a generic error message that either we have no data on the particular question or they are not authorized for access to whatever data we have on the particular question. Since the webapp only knows that the database search returned no data, it has no idea whether there is no data in the system or just no data accessible by this user's permissions.

If a user has access to multiple areas within the webapp, they can choose the generic home page or an area specific home page, but even those pages are built on the fly. E.g., someone might have worldwide access, but their concentration is on Europe, so their default homepage after logging in shows only recent data updates for Europe. 

Then again, I may be missing the whole point here.

Bryan



From ch-tbnl at bobobeach.com  Sat Apr 12 22:25:33 2008
From: ch-tbnl at bobobeach.com (Cyrus Harmon)
Date: Sat, 12 Apr 2008 15:25:33 -0700
Subject: [hunchentoot-devel] Re: hunchentoot authorization
In-Reply-To: <200804121517.00037.bryan.emrys@gmail.com>
References: <646F5ECD-F5B7-41A9-8162-6D565E122A14@cyrusharmon.org>
	<u8wzkbzzk.fsf@agharta.de>
	<DA33FF0D-C2C0-4617-8952-93120A8B9E9A@bobobeach.com>
	<200804121517.00037.bryan.emrys@gmail.com>
Message-ID: <8444AC63-E13A-4879-ADFA-E1ECA1CB49A8@bobobeach.com>


I would argue that this sort of plumbing sits between the server and  
the application. It's the kind of infrastructure that multiple  
application uses and it probably needs to know something about the  
server in order to function properly. But the whole distinction  
between application and server is rather nebulous and arbitrary.

What I have in mind is a relative simple, extensible system for  
managing users/passwords/groups and for allowing one to server pages  
with various scenarios in mind, such as requiring that a user become  
an authenticated user before seeing certain pages, that different  
users see different content based on various properties, etc...  
Clearly more complex applications may have more demanding requirements  
for this functionality, but a basic, extensible infrastructure sitting  
on top of hunchentoot seems like it would enable folks to have a leg  
up when beginning to write the kind of apps you mention.

Cyrus

On Apr 12, 2008, at 3:16 PM, Bryan Emrys wrote:

> Is this a server function or an app function? By the time you start  
> rolling out full ACL capability, aren't you pretty far removed from  
> the server?
>
> On the app I'm maintaining (non-lisp), data can come in from several  
> sources with different licenses. Some of the data sources give us  
> site-wide licenses, others are limited to certain specific  
> individuals. So it isn't just a question of is the user authorized  
> to see a certain area of the site (and, if so, do they have read/add/ 
> edit capabilities within that area), but data searches need to see  
> if this chunk of data has license restrictions which further limit  
> the read/add/edit capability for that specific piece of data.
>
> So a typical internal user will say - log me in and the app knows  
> that this user is limited to area 123.
> The user asks "tell me everything we know about  in XYZ in Thailand"
> The app then looks for everything in the system about XYZ in  
> Thailand which this user is allowed to view and builds a page from  
> that data.
>
> Since "pages" are built on the fly from the database search results,  
> there is no such thing as an "authorized page". A different user who  
> may be on more or fewer or just different data source licenses would  
> see a completely "different" page. (Different in the sense that the  
> data on the page would be different - the url would be exactly the  
> same.) The user could even see a page with no data, just a generic  
> error message that either we have no data on the particular question  
> or they are not authorized for access to whatever data we have on  
> the particular question. Since the webapp only knows that the  
> database search returned no data, it has no idea whether there is no  
> data in the system or just no data accessible by this user's  
> permissions.
>
> If a user has access to multiple areas within the webapp, they can  
> choose the generic home page or an area specific home page, but even  
> those pages are built on the fly. E.g., someone might have worldwide  
> access, but their concentration is on Europe, so their default  
> homepage after logging in shows only recent data updates for Europe.
>
> Then again, I may be missing the whole point here.
>
> Bryan
>



From kiuma72 at gmail.com  Sat Apr 12 22:50:33 2008
From: kiuma72 at gmail.com (Andrea Chiumenti)
Date: Sat, 12 Apr 2008 22:50:33 +0000
Subject: [hunchentoot-devel] Sessions for realm aware Realm
In-Reply-To: <fd2982320804121128k22efbd92h261e38a3c9f0640f@mail.gmail.com>
References: <4d3bc9370804120546q6a3a6b98qbca788446bd8e7d6@mail.gmail.com>
	<fd2982320804120615n58e7cc51pc67dd9316180e66d@mail.gmail.com>
	<fd2982320804120617s5d898482o2d46687c0aee3df9@mail.gmail.com>
	<4d3bc9370804120714p1d68ea71xb0fceecb29d03f9d@mail.gmail.com>
	<fd2982320804121128k22efbd92h261e38a3c9f0640f@mail.gmail.com>
Message-ID: <4d3bc9370804121550r3838ae01o65600abfbc81c6a8@mail.gmail.com>

cookies must be bound to a specific address (I might even proxify two
applications on different address names (host1 and host2).
Obviously we have to keep [cookie<--(n..1)--->realm], so that a user
can eliminate cookies for specific applications (I use tons of tabs
with my FF browser).
 In short I think that cookies must be bound to addresses(path) and
must not stay only in "/" for a greater flexibility.
And this extension should not change the default behaviour

kiuma

On Sat, Apr 12, 2008 at 6:28 PM, Hans H?bner <hans at huebner.org> wrote:
> Can we get away with extending START-SESSION by a realm argument that
>  is added to or used instead of the *SESSION-COOKIE-NAME* to determine
>  the cookie name or session id parameter?
>
>  -Hans
>
>
>  On 4/12/08, Andrea Chiumenti <kiuma72 at gmail.com> wrote:
>
>
> > Not completely correct.
>  >
>  >  Suppose we want to "deploy" two applications in the same hunchentoot
>  >  server instance.
>  >  First, since they are two applications, they must have their own
>  >  cookie each one.
>  >
>  >
>  >  Now we have two options:
>  >  1) let them to share the same session data, then bind the two
>  >  applications to the same realm,
>  >  2) make the two applications completely independents, then bind them
>  >  to two different realms.
>  >
>  >  So,
>  >  1 request to only 1 session
>  >  and one session may be shared or not.
>  >
>  >  kiuma
>  >
>  >
>  >
>  >
>  >
>  >  On Sat, Apr 12, 2008 at 1:17 PM, Hans H?bner <hans at huebner.org> wrote:
>  >  > On 4/12/08, Hans H?bner <hans at huebner.org> wrote:
>  >  >  >  if I understand your source code right, what you need is a realm
>  >  >  >  argument to START-SESSION that makes it possible to have multiple
>  >  >  >  sessions on one Hunchentoot server.  Correct?
>  >  >
>  >  >  Well, I realised that my description of the feature is not quite
>  >  >  right, another try:  You want to have the option to use multiple
>  >  >  sessions within one request, qualified by a realm argument.  Or what?
>  >  >  It would really help if you would describe your requirements yourself
>  >  >  instead of letting us guess from your example source code.
>  >  >
>  >  >  -Hans
>  >  >
>  >  >
>  >
>  > > _______________________________________________
>  >  >  tbnl-devel site list
>  >  >  tbnl-devel at common-lisp.net
>  >  >  http://common-lisp.net/mailman/listinfo/tbnl-devel
>  >  >
>  >  _______________________________________________
>  >  tbnl-devel site list
>  >  tbnl-devel at common-lisp.net
>  >  http://common-lisp.net/mailman/listinfo/tbnl-devel
>  >
>  _______________________________________________
>  tbnl-devel site list
>  tbnl-devel at common-lisp.net
>  http://common-lisp.net/mailman/listinfo/tbnl-devel
>


From bryan.emrys at gmail.com  Sat Apr 12 23:24:51 2008
From: bryan.emrys at gmail.com (Bryan Emrys)
Date: Sat, 12 Apr 2008 16:24:51 -0700
Subject: [hunchentoot-devel] Re: hunchentoot authorization
In-Reply-To: <8444AC63-E13A-4879-ADFA-E1ECA1CB49A8@bobobeach.com>
References: <646F5ECD-F5B7-41A9-8162-6D565E122A14@cyrusharmon.org>
	<200804121517.00037.bryan.emrys@gmail.com>
	<8444AC63-E13A-4879-ADFA-E1ECA1CB49A8@bobobeach.com>
Message-ID: <200804121624.51331.bryan.emrys@gmail.com>

Agreed. I got too mono-focused there. 

Bryan

On Saturday 12 April 2008 03:25:33 pm Cyrus Harmon wrote:
> 
> I would argue that this sort of plumbing sits between the server and  
> the application. It's the kind of infrastructure that multiple  
> application uses and it probably needs to know something about the  
> server in order to function properly. But the whole distinction  
> between application and server is rather nebulous and arbitrary.
> 
> What I have in mind is a relative simple, extensible system for  
> managing users/passwords/groups and for allowing one to server pages  
> with various scenarios in mind, such as requiring that a user become  
> an authenticated user before seeing certain pages, that different  
> users see different content based on various properties, etc...  
> Clearly more complex applications may have more demanding requirements  
> for this functionality, but a basic, extensible infrastructure sitting  
> on top of hunchentoot seems like it would enable folks to have a leg  
> up when beginning to write the kind of apps you mention.
> 
> Cyrus
> 
> On Apr 12, 2008, at 3:16 PM, Bryan Emrys wrote:
> 
> > Is this a server function or an app function? By the time you start  
> > rolling out full ACL capability, aren't you pretty far removed from  
> > the server?
> >
> > On the app I'm maintaining (non-lisp), data can come in from several  
> > sources with different licenses. Some of the data sources give us  
> > site-wide licenses, others are limited to certain specific  
> > individuals. So it isn't just a question of is the user authorized  
> > to see a certain area of the site (and, if so, do they have read/add/ 
> > edit capabilities within that area), but data searches need to see  
> > if this chunk of data has license restrictions which further limit  
> > the read/add/edit capability for that specific piece of data.
> >
> > So a typical internal user will say - log me in and the app knows  
> > that this user is limited to area 123.
> > The user asks "tell me everything we know about  in XYZ in Thailand"
> > The app then looks for everything in the system about XYZ in  
> > Thailand which this user is allowed to view and builds a page from  
> > that data.
> >
> > Since "pages" are built on the fly from the database search results,  
> > there is no such thing as an "authorized page". A different user who  
> > may be on more or fewer or just different data source licenses would  
> > see a completely "different" page. (Different in the sense that the  
> > data on the page would be different - the url would be exactly the  
> > same.) The user could even see a page with no data, just a generic  
> > error message that either we have no data on the particular question  
> > or they are not authorized for access to whatever data we have on  
> > the particular question. Since the webapp only knows that the  
> > database search returned no data, it has no idea whether there is no  
> > data in the system or just no data accessible by this user's  
> > permissions.
> >
> > If a user has access to multiple areas within the webapp, they can  
> > choose the generic home page or an area specific home page, but even  
> > those pages are built on the fly. E.g., someone might have worldwide  
> > access, but their concentration is on Europe, so their default  
> > homepage after logging in shows only recent data updates for Europe.
> >
> > Then again, I may be missing the whole point here.
> >
> > Bryan
> >
> 
> 




From rsynnott at gmail.com  Sun Apr 13 00:45:14 2008
From: rsynnott at gmail.com (Robert Synnott)
Date: Sun, 13 Apr 2008 01:45:14 +0100
Subject: [hunchentoot-devel] Re: hunchentoot authorization
In-Reply-To: <200804121624.51331.bryan.emrys@gmail.com>
References: <646F5ECD-F5B7-41A9-8162-6D565E122A14@cyrusharmon.org>
	<200804121517.00037.bryan.emrys@gmail.com>
	<8444AC63-E13A-4879-ADFA-E1ECA1CB49A8@bobobeach.com>
	<200804121624.51331.bryan.emrys@gmail.com>
Message-ID: <24f203480804121745i62673019y843b47c9f1c8402a@mail.gmail.com>

To me, this seems like pushing Hunchentoot more in the direction of
being a web framework than just a webserver. Not that there's anything
wrong with that, of course, but it could probably be just as easily
done with a library that sits on top and implements a light-weight
framework.
Rob


From ch-tbnl at bobobeach.com  Sun Apr 13 01:21:55 2008
From: ch-tbnl at bobobeach.com (Cyrus Harmon)
Date: Sat, 12 Apr 2008 18:21:55 -0700
Subject: [hunchentoot-devel] Re: hunchentoot authorization
In-Reply-To: <24f203480804121745i62673019y843b47c9f1c8402a@mail.gmail.com>
References: <646F5ECD-F5B7-41A9-8162-6D565E122A14@cyrusharmon.org>
	<200804121517.00037.bryan.emrys@gmail.com>
	<8444AC63-E13A-4879-ADFA-E1ECA1CB49A8@bobobeach.com>
	<200804121624.51331.bryan.emrys@gmail.com>
	<24f203480804121745i62673019y843b47c9f1c8402a@mail.gmail.com>
Message-ID: <B441E8CB-FE35-4419-8FCD-E2ECB93C0333@bobobeach.com>


Robert,

Yes, I agree. This certainly doesn't have to be part of hunchentoot.  
However, I see an opportunity for lightweight hunchentoot-specific  
user authentication/authorization package that could provide this  
functionality. Moreover, some minor tweaks to hunchentoot might make  
this an easier task. I'd like to stay away from a full-fledged web  
framework ala UCW or weblocks, however, and I'm willing to 1) make  
this library totally hunchentoot-specific and 2) if necessary propose  
modifications to hunchentoot that would facilitate the implementation  
of this library. In particular, the hunchentoot dispatch stuff, while  
flexible, could, I think, be improved in ways that would make the  
implementation of this library more facile. But I'm just brainstorming  
at the moment and don't have any concrete examples, other than the  
fact that meta-dispatch stuff feels like it might be cleaner with some  
sort of CLOS custom method combination might. Then again, it's  
flexible enough that this can be implemented on top of the existing  
stuff with little penalty, so perhaps I should explore that instead of  
just writing windy emails...

Yes, to be clear, this discussion is more about my half-baked ideas  
for the future of hunchentoot-auth than it is about changes to  
hunchentoot to include some user authentication framework.

Thanks for listening,

Cyrus

On Apr 12, 2008, at 5:45 PM, Robert Synnott wrote:

> To me, this seems like pushing Hunchentoot more in the direction of
> being a web framework than just a webserver. Not that there's anything
> wrong with that, of course, but it could probably be just as easily
> done with a library that sits on top and implements a light-weight
> framework.
> Rob



From arjan at streamtech.nl  Sun Apr 13 10:11:39 2008
From: arjan at streamtech.nl (Arjan Wekking)
Date: Sun, 13 Apr 2008 12:11:39 +0200
Subject: [hunchentoot-devel] Re: hunchentoot authorization
In-Reply-To: <B441E8CB-FE35-4419-8FCD-E2ECB93C0333@bobobeach.com>
References: <646F5ECD-F5B7-41A9-8162-6D565E122A14@cyrusharmon.org>
	<200804121517.00037.bryan.emrys@gmail.com>
	<8444AC63-E13A-4879-ADFA-E1ECA1CB49A8@bobobeach.com>
	<200804121624.51331.bryan.emrys@gmail.com>
	<24f203480804121745i62673019y843b47c9f1c8402a@mail.gmail.com>
	<B441E8CB-FE35-4419-8FCD-E2ECB93C0333@bobobeach.com>
Message-ID: <2611F291-A195-4526-A5DD-7B2B69164A44@streamtech.nl>

On 13 apr 2008, at 03:21, Cyrus Harmon wrote:

> This certainly doesn't have to be part of hunchentoot.

Perhaps this can be resolved by considering Hunchentoot a web-server  
and, like Robert said, not a web application framework; if this deals  
with HTTP details (like HTTP layer authentication and authorization)  
the answer is simply 'yes'. If your authorization and authentication  
is not at the HTTP layer, I would say it is part of your application  
and not HTPP and thus should remain there.

Although a covers-everything web framework has allure at first; I've  
often experienced disappointment after actually using some due to un- 
layered or incomplete design forcing you to do it their way or having  
to use horrible workarounds and hacks that make you feel dirty.

However, there is definitely a place for frameworks that sit on top of  
a generic web-server with a good HTTP layer API. I hope Hunchentoot  
will remain being such a web-server.

In fact, I firmly believe there is even place for a layer in-between  
(think Python's WSGI but perhaps richer) so that web frameworks can be  
written in a web-server agnostic way and can perhaps even cooperate  
and nest each-other.

Woops, sorry for hijacking your thread with that - I'll get off my  
soapbox now ;)

-Arjan

> On Apr 12, 2008, at 5:45 PM, Robert Synnott wrote:
>
>> To me, this seems like pushing Hunchentoot more in the direction of
>> being a web framework than just a webserver. Not that there's  
>> anything
>> wrong with that, of course, but it could probably be just as easily
>> done with a library that sits on top and implements a light-weight
>> framework.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: smime.p7s
Type: application/pkcs7-signature
Size: 3405 bytes
Desc: not available
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20080413/9fd3726b/attachment.bin>

From michaelw+tbnl at foldr.org  Sun Apr 13 10:49:13 2008
From: michaelw+tbnl at foldr.org (Michael Weber)
Date: Sun, 13 Apr 2008 12:49:13 +0200
Subject: Dispatch mechanism (was: Re: [hunchentoot-devel] Re: hunchentoot
	authorization)
In-Reply-To: <B441E8CB-FE35-4419-8FCD-E2ECB93C0333@bobobeach.com>
References: <646F5ECD-F5B7-41A9-8162-6D565E122A14@cyrusharmon.org>
	<200804121517.00037.bryan.emrys@gmail.com>
	<8444AC63-E13A-4879-ADFA-E1ECA1CB49A8@bobobeach.com>
	<200804121624.51331.bryan.emrys@gmail.com>
	<24f203480804121745i62673019y843b47c9f1c8402a@mail.gmail.com>
	<B441E8CB-FE35-4419-8FCD-E2ECB93C0333@bobobeach.com>
Message-ID: <1321DD8F-EA59-46AF-9C29-C7FFFA1735EA@foldr.org>


On Apr 13, 2008, at 03:21 , Cyrus Harmon wrote:
> I'd like to stay away from a full-fledged web framework ala UCW or  
> weblocks

Yes. please.  I use Hunchentoot primarily as a thin layer above HTTP,  
which shields me from dealing with the raw bytes on the wire.  Also, I  
have to say I haven't seen a convincing CL web framework yet.  They  
all seem to be UI centric, whereas I am dealing mostly with resources.

> I'm willing to 1) make this library totally hunchentoot-specific and  
> 2) if necessary propose modifications to hunchentoot that would  
> facilitate the implementation of this library.

I have no problem with that.  For me, the only reason to prefer  
something else over HT would be if I couldn't deploy behind mod_proxy,  
and then I'd probably rather write an adaptor for that situation  
(FastCGI, WSGI, ...).

> In particular, the hunchentoot dispatch stuff, while flexible,  
> could, I think, be improved in ways that would make the  
> implementation of this library more facile.

I actually find it overly flexible.  (This is perhaps another of the  
"organic growth" areas.)
There are several ways to plug into the dispatcher.  At the moment, I  
am using this:

   (defvar *toplevel-routing-table*
     (let ((rt (make-instance 'ht-routing-table)))
       (shiftf (get-routes rt) hunchentoot:*dispatch-table* rt)
       rt))

   (defmethod hunchentoot:dispatch-request ((table routing-table))
     (let ((controller (find-controller table *request*)))
       (handle-request controller *request*)))

However, another option for me would be to just push

   (lambda ()
     (hunchentoot:dispatch-request *toplevel-routing-table* *request*))

onto hunchentoot:*dispatch-table*.  And I haven't even look at the  
meta-dispatcher stuff and starting multiple server instances.

There's probably a way to simplify all this without losing any power  
or convenience.


Cheers,
Michael
BTW: The reasons behind all this:
* I like the mappings between URLs and handlers a little more  
descriptive than bare function designators, for example, to print out  
the mapping or appropriate Apache config stanzas.  So I use CLOS  
objects.  Alternatively, I could have used (:metaclass funcallable- 
standard-class).

* I like to be able to rearrange URL mappings while running in  
development.  (make-prefix-matcher "/foo/") is a little too static for  
my taste.

* I bundle several end points (handlers) together (into a  
"controller"), because on their own, they don't make sense.  Also, the  
end points don't know anything about the URL they are mapped to.

* I can deploy a single controller several times on different URL  
routes (e.g., "/~foo/...", "/~bar/...", etc.).  The routing dissects  
the URL and provides parameters to controller and end points.   
Deploying multiple "web apps" comes for free.

* Authentication is done by Apache, for the moment, because it's  
convenient and works for files served statically, too.

* Authorization is done by Apache and by controllers (for, say, DB  
access), because all end points are usually subject to the same  
rules.  End points can do additional checks with finer granularity.



From ch-tbnl at bobobeach.com  Sun Apr 13 19:27:33 2008
From: ch-tbnl at bobobeach.com (Cyrus Harmon)
Date: Sun, 13 Apr 2008 12:27:33 -0700
Subject: Dispatch mechanism (was: Re: [hunchentoot-devel] Re: hunchentoot
	authorization)
In-Reply-To: <1321DD8F-EA59-46AF-9C29-C7FFFA1735EA@foldr.org>
References: <646F5ECD-F5B7-41A9-8162-6D565E122A14@cyrusharmon.org>
	<200804121517.00037.bryan.emrys@gmail.com>
	<8444AC63-E13A-4879-ADFA-E1ECA1CB49A8@bobobeach.com>
	<200804121624.51331.bryan.emrys@gmail.com>
	<24f203480804121745i62673019y843b47c9f1c8402a@mail.gmail.com>
	<B441E8CB-FE35-4419-8FCD-E2ECB93C0333@bobobeach.com>
	<1321DD8F-EA59-46AF-9C29-C7FFFA1735EA@foldr.org>
Message-ID: <FF316EC3-8248-4A89-9DEC-12E95B9A7CE1@bobobeach.com>


On Apr 13, 2008, at 3:49 AM, Michael Weber wrote:

> I actually find it overly flexible.  (This is perhaps another of the  
> "organic growth" areas.)
> There are several ways to plug into the dispatcher.  At the moment,  
> I am using this:

Yes, I think this is part of the challenge here. There are many ways  
to plug the sort of functionality I'm thinking of into hunchentoot.  
I'm not satisfied with the current approach taken by hunchentoot-auth  
and the myriad of choices for plugging this stuff in is what initially  
precipitated this discussion.

At the risk of taking this discussion from the philosophical to the  
practical, allow me to discuss some options for wedging in the  
authorization stuff.

+ authorized-page macro

The existing approach is an authorized-page -style macro that wraps  
each page and does the following:

* check if an https connection is required and if so that we're  
actually using an https connection otherwise, redirect to an https  
page on the appropriate port.
* either check that the supplied user and password are correct or that  
the user's session was properly authenticated. If necessary, squirrel  
away the user name in a per-session hash-table and set a flag that in  
a per-session hash-table that the user is authenticated.

The disadvantage of this approach is that it requires wrapping the  
code that generates each page with the authorized-page macro. One  
can't take arbitrary request handling code and make the page require  
authorization without somehow wrapping it, or another function that  
calls it, with this macro.

+ *meta-dispatcher*

One could rig up *meta-dispatcher* such that it checked for  
authorization and possibly redirect things along the way. The problem  
with this is that there is only one meta-dispatcher, so you only get  
to do this once per hunchentoot instance.

And, of course, one could override the value of *dispatch-table*,  
which is what the default *meta-dispatcher* returns.

+ server-dispatch-table

Similarly to the case of *meta-dispatcher*, one could use the dispatch- 
table slot of the server instance to hijack the dispatch and check for  
authentication. But it's not clear to me how the elements of this  
table should be ordered.

Interestingly, there's a dispatch-request generic function that could  
be used with a suitably defined class.

Clearly there's plenty of rope for extensibility here, the challenge,  
for hunchentoot-auth at least, is figuring which of these hooks to  
exploit.

>  (defvar *toplevel-routing-table*
>    (let ((rt (make-instance 'ht-routing-table)))
>      (shiftf (get-routes rt) hunchentoot:*dispatch-table* rt)
>      rt))
>
>  (defmethod hunchentoot:dispatch-request ((table routing-table))
>    (let ((controller (find-controller table *request*)))
>      (handle-request controller *request*)))
>
> However, another option for me would be to just push
>
>  (lambda ()
>    (hunchentoot:dispatch-request *toplevel-routing-table* *request*))
>
> onto hunchentoot:*dispatch-table*.  And I haven't even look at the  
> meta-dispatcher stuff and starting multiple server instances.

Right. Multiple server-instances is another issue and it becomes  
important for what i'm doing because I use two server instances, one  
for http and one for https. There's no built-in infrastructure for  
managing multiple "servers". One could imagine some sort of meta- 
server (or renaming the server class to a listener and allowing for  
the server to have multiple listeners, but I guess that's just a  
nomenclature issue).

> There's probably a way to simplify all this without losing any power  
> or convenience.

Right.

> Cheers,
> Michael
> BTW: The reasons behind all this:
> * I like the mappings between URLs and handlers a little more  
> descriptive than bare function designators, for example, to print  
> out the mapping or appropriate Apache config stanzas.  So I use CLOS  
> objects.  Alternatively, I could have used (:metaclass funcallable- 
> standard-class).

I agree. I like having more of the "metadata" kept with the function  
too.

> * I like to be able to rearrange URL mappings while running in  
> development.  (make-prefix-matcher "/foo/") is a little too static  
> for my taste.
>
> * I bundle several end points (handlers) together (into a  
> "controller"), because on their own, they don't make sense.  Also,  
> the end points don't know anything about the URL they are mapped to.
>
> * I can deploy a single controller several times on different URL  
> routes (e.g., "/~foo/...", "/~bar/...", etc.).  The routing dissects  
> the URL and provides parameters to controller and end points.   
> Deploying multiple "web apps" comes for free.
>
> * Authentication is done by Apache, for the moment, because it's  
> convenient and works for files served statically, too.

Hmm... I've taken the perhaps crazy approach of using ht for  
everything, static files, CGI scripts, etc...

> * Authorization is done by Apache and by controllers (for, say, DB  
> access), because all end points are usually subject to the same  
> rules.  End points can do additional checks with finer granularity.

Thanks for your comments,

Cyrus



From lispercat at gmail.com  Mon Apr 14 00:03:10 2008
From: lispercat at gmail.com (Andrei Stebakov)
Date: Sun, 13 Apr 2008 20:03:10 -0400
Subject: [hunchentoot-devel] interning strings under Hunchentoot
Message-ID: <affe56e00804131703k40453883re2680aa6d90c3da6@mail.gmail.com>

If I try to intern a string so I can call a function with this name,
Hunchentoot returns an error that this function is not defined.
For example, if in a HT request handler I call (apply 'some-func '("str1"
"str2")) everything is OK, the function is called.
If I call it like (apply (intern "SOME-FUNC") '("str1" "str2")) an exception
occurs saying that SOME-FUNC is not defined.
I need it to compose a function name by concatenating strings.
BTW, when I do the same thing from REPL, both ways work.
I am still just learing lisp and maybe this is not specifically HT related
question, but I'd like to know why it happens.
I am using hunchentoot-0.14.2 and sbcl 1.0.6.

Thank you,
Andrew
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20080413/7ad1fde5/attachment.html>

From danielgackle at gmail.com  Mon Apr 14 00:23:00 2008
From: danielgackle at gmail.com (Daniel Gackle)
Date: Sun, 13 Apr 2008 18:23:00 -0600
Subject: [hunchentoot-devel] interning strings under Hunchentoot
In-Reply-To: <affe56e00804131703k40453883re2680aa6d90c3da6@mail.gmail.com>
References: <affe56e00804131703k40453883re2680aa6d90c3da6@mail.gmail.com>
Message-ID: <57952f8b0804131723i11b07fb1u604402cc1a78e121@mail.gmail.com>

Andrei,

Since you don't specify :package in (intern "SOME-FUNC"), the symbol
returned will be in the current package. Probably that's not the package in
which you defined some-func.

Daniel


On Sun, Apr 13, 2008 at 6:03 PM, Andrei Stebakov <lispercat at gmail.com>
wrote:

> If I try to intern a string so I can call a function with this name,
> Hunchentoot returns an error that this function is not defined.
> For example, if in a HT request handler I call (apply 'some-func '("str1"
> "str2")) everything is OK, the function is called.
> If I call it like (apply (intern "SOME-FUNC") '("str1" "str2")) an
> exception occurs saying that SOME-FUNC is not defined.
> I need it to compose a function name by concatenating strings.
> BTW, when I do the same thing from REPL, both ways work.
> I am still just learing lisp and maybe this is not specifically HT related
> question, but I'd like to know why it happens.
> I am using hunchentoot-0.14.2 and sbcl 1.0.6.
>
> Thank you,
> Andrew
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20080413/5a03b38a/attachment.html>

From lispercat at gmail.com  Mon Apr 14 11:45:55 2008
From: lispercat at gmail.com (Andrei Stebakov)
Date: Mon, 14 Apr 2008 07:45:55 -0400
Subject: [hunchentoot-devel] interning strings under Hunchentoot
In-Reply-To: <57952f8b0804131723i11b07fb1u604402cc1a78e121@mail.gmail.com>
References: <affe56e00804131703k40453883re2680aa6d90c3da6@mail.gmail.com>
	<57952f8b0804131723i11b07fb1u604402cc1a78e121@mail.gmail.com>
Message-ID: <affe56e00804140445l3839b10fhc8b2a8e32c74b06e@mail.gmail.com>

Right. Thank you, Daniel!

On 4/13/08, Daniel Gackle <danielgackle at gmail.com> wrote:
>
> Andrei,
>
> Since you don't specify :package in (intern "SOME-FUNC"), the symbol
> returned will be in the current package. Probably that's not the package in
> which you defined some-func.
>
> Daniel
>
>
> On Sun, Apr 13, 2008 at 6:03 PM, Andrei Stebakov <lispercat at gmail.com>
> wrote:
>
> > If I try to intern a string so I can call a function with this name,
> > Hunchentoot returns an error that this function is not defined.
> > For example, if in a HT request handler I call (apply 'some-func
> > '("str1" "str2")) everything is OK, the function is called.
> > If I call it like (apply (intern "SOME-FUNC") '("str1" "str2")) an
> > exception occurs saying that SOME-FUNC is not defined.
> > I need it to compose a function name by concatenating strings.
> > BTW, when I do the same thing from REPL, both ways work.
> > I am still just learing lisp and maybe this is not specifically HT
> > related question, but I'd like to know why it happens.
> > I am using hunchentoot-0.14.2 and sbcl 1.0.6.
> >
> > Thank you,
> > Andrew
> >
> > _______________________________________________
> > tbnl-devel site list
> > tbnl-devel at common-lisp.net
> > http://common-lisp.net/mailman/listinfo/tbnl-devel
> >
>
>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <https://mailman.common-lisp.net/pipermail/tbnl-devel/attachments/20080414/199732e8/attachment.html>

From jeffrey at cunningham.net  Wed Apr 16 12:43:59 2008
From: jeffrey at cunningham.net (Jeff Cunningham)
Date: Wed, 16 Apr 2008 05:43:59 -0700
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
Message-ID: <4805F48F.4080409@cunningham.net>

Hans H?bner wrote:
> Hi,
>
> I'm planning to make some substantial changes to Hunchentoot and it
> would be helpful if I could remove mod_lisp support in this process.
>
> If you are using Hunchentoot with mod_lisp, please let us know.
>
> Thanks,
> Hans
>   
I hope I'm not too late to provide input on this question - I currently 
have six servers running behind mod_lisp. It would be a lot of unwelcome 
work to convert these to mod_proxy.

--Jeff


From hans at huebner.org  Thu Apr 17 09:55:50 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Thu, 17 Apr 2008 11:55:50 +0200
Subject: [hunchentoot-devel] Hunchentoot refactoring status report
Message-ID: <fd2982320804170255g13ed13b2wd2898de658d49ead@mail.gmail.com>

Hi,

I have made a first round through Hunchentoot with the goals being:

- Remove system specific code, relying on common compatibility libraries instead
- Make single threaded operation a run-time option
- Add timeout support for more platforms
- Factor out SSL specific code so that conditional code is reduced
- Remove mod_lisp support to ease refactoring and simplify the code

I met most of these goals:

- Instead of using functions from port-*.lisp, Hunchentoot now depends
  on bordeaux-threads for multiple thread support and on usocket for
  socket i/o.  The GET-BACKTRACE function still remains as being
  non-portable.

- Threading behavior is now controller by a CONNECTION-MANAGER.  Every
  SERVER object has one CONNECTION-MANAGER and delegates listening and
  connection processing to that instance.  Currently, there exist two
  CONNECTION-MANAGER classes: SINGLE-THREADED-CONNECTION-MANAGER
  listens and processes connections synchronously,
  ONE-THREAD-PER-CONNECTION-MANAGER listens in a separate thread and
  processes each connection in a new thread, as Hunchentoot did on
  multi-threaded platforms until now.  The API for START-SERVER
  supports a THREADED keyword argument for simplicity, but it may be
  desirable to implement other CONNECTION-MANAGER classes in the
  future (for example to pool threads and/or separate connection
  management from request execution).

Timeouts which are really an issue that is hard to solve, as there is
no cross-implementation agreement on what timeouts are and how they
should be implemented.  As I need to make progress, I have added a
platform specific SET-TIMEOUTS function which uses whatever mechanism
the Lisp platform offers.  I have removed the setting for separate
read and write timeouts as I don't think that it is really useful make
the distinction, but if someone has a really good use case, I may be
adding them.

I am currently testing my changes on more platforms and compilers.
CCL and SBCL work fine, Lispworks is under investigation, I'll also
look at CLISP later on.  If there are other platforms that you'd like
to see supported in the future, please check out the branch and send
me patches.

Branch SVN URL:

http://common-lisp.net/project/tbnl/svn/branches/hans

Trac URL for browsing:

http://trac.common-lisp.net/tbnl/browser/branches/hans

RSS URL for commits:

http://trac.common-lisp.net/tbnl/timeline?changeset=on&max=50&daysback=90&format=rss


From quasilists at gmail.com  Fri Apr 18 10:35:49 2008
From: quasilists at gmail.com (Abhijit Rao)
Date: Fri, 18 Apr 2008 16:05:49 +0530
Subject: [hunchentoot-devel] mod_lisp anyone?
In-Reply-To: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
References: <fd2982320804090239t1d4e48b8q8713b9e245f8286d@mail.gmail.com>
Message-ID: <C03F51E8-F5BC-42FA-B13D-E562537CF0C7@gmail.com>

Hey,

I shifted to mod_proxy when I shifted from TBNL to Hunchentoot. :)  We  
have run it under heavy load at www.cleartrip.com and it works like a  
charm.  There are advantages of running behind Apache(s) and  
especially so as independent proxied application servers. It's also a  
cleaner design IMHO.

Best of luck & thanks!

quasi


On 09-Apr-08, at 3:09 PM, Hans H?bner wrote:
> Hi,
>
> I'm planning to make some substantial changes to Hunchentoot and it
> would be helpful if I could remove mod_lisp support in this process.
>
> If you are using Hunchentoot with mod_lisp, please let us know.
>
> Thanks,
> Hans
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel



From ebzzry at gmail.com  Thu Apr 24 07:05:44 2008
From: ebzzry at gmail.com (Rommel Martinez)
Date: Thu, 24 Apr 2008 15:05:44 +0800
Subject: [hunchentoot-devel] How to capture the server instance
Message-ID: <391934950804240005i50c4a35aj39f7e819c732e31@mail.gmail.com>

Is there a way to "capture" the server instance of Hunchentoot
when I start the server like the following (yes I haven't bound it
to a variable using say DEFVAR or DEFPARAMETER):

    CL-USER> (hunchentoot:start-server :port 9000)
    #<HUNCHENTOOT::SERVER {61917E79}>

So that I can do something like the following when I want to
stop the server:

    CL-USER> (hunchentoot:stop-server *foo*)

-- 
Rommel M. Martinez <ebzzry at gmail.com>


From edi at agharta.de  Thu Apr 24 07:17:23 2008
From: edi at agharta.de (Edi Weitz)
Date: Thu, 24 Apr 2008 09:17:23 +0200
Subject: [hunchentoot-devel] How to capture the server instance
In-Reply-To: <391934950804240005i50c4a35aj39f7e819c732e31@mail.gmail.com>
	(Rommel Martinez's message of "Thu, 24 Apr 2008 15:05:44 +0800")
References: <391934950804240005i50c4a35aj39f7e819c732e31@mail.gmail.com>
Message-ID: <u3apben7g.fsf@agharta.de>

On Thu, 24 Apr 2008 15:05:44 +0800, "Rommel Martinez" <ebzzry at gmail.com> wrote:

> Is there a way to "capture" the server instance of Hunchentoot when
> I start the server like the following (yes I haven't bound it to a
> variable using say DEFVAR or DEFPARAMETER):
>
>     CL-USER> (hunchentoot:start-server :port 9000)
>     #<HUNCHENTOOT::SERVER {61917E79}>
>
> So that I can do something like the following when I want to stop
> the server:
>
>     CL-USER> (hunchentoot:stop-server *foo*)

What's wrong with 

  (setq *foo* (hunchentoot:start-server :port 9000))

?


From stassats at gmail.com  Thu Apr 24 09:06:09 2008
From: stassats at gmail.com (Stas Boukarev)
Date: Thu, 24 Apr 2008 13:06:09 +0400
Subject: [hunchentoot-devel] How to capture the server instance
In-Reply-To: <391934950804240005i50c4a35aj39f7e819c732e31@mail.gmail.com>
References: <391934950804240005i50c4a35aj39f7e819c732e31@mail.gmail.com>
Message-ID: <9f0fec110804240206h2dae0334p53e57ae187fe1df9@mail.gmail.com>

CL binds previous three returned values in the REPL to *, **, and ***
respectivly.

2008/4/24, Rommel Martinez <ebzzry at gmail.com>:
> Is there a way to "capture" the server instance of Hunchentoot
> when I start the server like the following (yes I haven't bound it
> to a variable using say DEFVAR or DEFPARAMETER):
>
>     CL-USER> (hunchentoot:start-server :port 9000)
>     #<HUNCHENTOOT::SERVER {61917E79}>
>
> So that I can do something like the following when I want to
> stop the server:
>
>     CL-USER> (hunchentoot:stop-server *foo*)
>
> --
> Rommel M. Martinez <ebzzry at gmail.com>
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel
>


-- 
With Best Regards, Stas.


From urym at two-bytes.com  Tue Apr 29 00:21:39 2008
From: urym at two-bytes.com (Ury Marshak)
Date: Tue, 29 Apr 2008 03:21:39 +0300
Subject: [hunchentoot-devel] Re: GET-BACKTRACE
In-Reply-To: <fd2982320804170255g13ed13b2wd2898de658d49ead@mail.gmail.com>
References: <fd2982320804170255g13ed13b2wd2898de658d49ead@mail.gmail.com>
Message-ID: <48166A13.2070900@two-bytes.com>

? wrote:

>   The GET-BACKTRACE function still remains as being
>   non-portable.
>
>   
Is there a possibility of splitting it off to a separate library too? 
It'll be just the thin
portability layer, of course, but I can see some other possible uses for 
a hypothetical,
well, say, chardonnay-backtraces library. For example some (non-web) 
delivered
applications that could write backtraces to a log file to be examined by 
the author later,
or to be emailed to the author.

Cheers,
Ury


From edi at agharta.de  Tue Apr 29 06:18:46 2008
From: edi at agharta.de (Edi Weitz)
Date: Tue, 29 Apr 2008 08:18:46 +0200
Subject: [hunchentoot-devel] Re: GET-BACKTRACE
In-Reply-To: <48166A13.2070900@two-bytes.com> (Ury Marshak's message of
	"Tue, 29 Apr 2008 03:21:39 +0300")
References: <fd2982320804170255g13ed13b2wd2898de658d49ead@mail.gmail.com>
	<48166A13.2070900@two-bytes.com>
Message-ID: <uskx5ji9l.fsf@agharta.de>

On Tue, 29 Apr 2008 03:21:39 +0300, Ury Marshak <urym at two-bytes.com> wrote:

> Is there a possibility of splitting it off to a separate library
> too?

Sure there is.  I think the main problem is to find someone who
packages, documents, and maintains it.


From gwking at metabang.com  Tue Apr 29 11:04:19 2008
From: gwking at metabang.com (Gary King)
Date: Tue, 29 Apr 2008 07:04:19 -0400
Subject: [hunchentoot-devel] Re: GET-BACKTRACE
In-Reply-To: <uskx5ji9l.fsf@agharta.de>
References: <fd2982320804170255g13ed13b2wd2898de658d49ead@mail.gmail.com>
	<48166A13.2070900@two-bytes.com> <uskx5ji9l.fsf@agharta.de>
Message-ID: <4800B949-CEA7-47B7-9A76-DF0D3CAAF594@metabang.com>

I'll volunteer.

On Apr 29, 2008, at 2:18 AM, Edi Weitz wrote:
> On Tue, 29 Apr 2008 03:21:39 +0300, Ury Marshak <urym at two-bytes.com>  
> wrote:
>
>> Is there a possibility of splitting it off to a separate library
>> too?
>
> Sure there is.  I think the main problem is to find someone who
> packages, documents, and maintains it.
> _______________________________________________
> tbnl-devel site list
> tbnl-devel at common-lisp.net
> http://common-lisp.net/mailman/listinfo/tbnl-devel

--
Gary Warren King, metabang.com
Cell: (413) 559 8738
Fax: (206) 338-4052
gwkkwg on Skype * garethsan on AIM






From hans at huebner.org  Tue Apr 29 11:26:40 2008
From: hans at huebner.org (=?ISO-8859-1?Q?Hans_H=FCbner?=)
Date: Tue, 29 Apr 2008 13:26:40 +0200
Subject: [hunchentoot-devel] Re: GET-BACKTRACE
In-Reply-To: <4800B949-CEA7-47B7-9A76-DF0D3CAAF594@metabang.com>
References: <fd2982320804170255g13ed13b2wd2898de658d49ead@mail.gmail.com>
	<48166A13.2070900@two-bytes.com> <uskx5ji9l.fsf@agharta.de>
	<4800B949-CEA7-47B7-9A76-DF0D3CAAF594@metabang.com>
Message-ID: <fd2982320804290426l65289a34m2ed251a75ef4747c@mail.gmail.com>

On Tue, Apr 29, 2008 at 1:04 PM, Gary King <gwking at metabang.com> wrote:
> I'll volunteer.

Great, keep us posted!  I'll integrate the trivial-backtrace package
into my Hunchentoot branch once it exists.  It'll be some more weeks
before I can think about getting a Hunchentoot release done from the
branch anyway.

-Hans