Re: mod_lisp for guile

From: Alan Grover <awgrover@mail.msen.com>
Cc: guile-user@gnu.org
Subject: Re: mod_lisp for guile
Date: Mon, 05 Dec 2005 12:21:07 -0500	[thread overview]
Message-ID: <43947703.9030401@mail.msen.com> (raw)
In-Reply-To: <87oe3xgopj.fsf@ossau.uklinux.net>

Neil Jerram wrote:

>> Hi Alan,
>>
>> I'm just picking up my interest in this again, and I can't see why you
>> think the lazy list approach will be practical.  For two reasons:
>>
>> 1. If you are going to reuse the Apache socket (i.e. Keep-Socket: 1),
>>    you need to read, sooner or later, all the available data for the
>>    current request, so you might as well read it all upfront and then
>>    present it to the caller as an alist.

Re-use of the socket seems to have several issues. I've deferred
thinking too much about it (and thus, haven't checked exactly how it
works), but have noted the following:

It seems to serialize http transactions. You have to complete the entire
request/response before handling the next one. Which is not so good if
you want to handle simultaneous requests. This is a generalization of
the problem you noted, since you have to respond before the next request
can even be seen.

As I develop my mod_lisp related code, I'll note the
trade-offs/implications of Keep-Socket. But, don't hold your breath for
the next release.

>> 2. Even if you're not reusing the Apache socket, you don't know where
>>    a given header will be in the stream.  So the chances are your
>>    caller will have to read most of the available data anyway in order
>>    to find the headers that it is interested again.  So again, might
>>    as well read the whole lot upfront and provide a more convenient
>>    interface.
>>
>> Have I missed something or misunderstood you?

Actually, your comments are interesting, since you assumed I meant a
lazy-list at the per-header level. Hmmm. Weird. Even intriguing: why
read the rest of the request if you get to a header that you tells you
to give up?

But, to address the question. Yes, there's a slight misunderstanding.

I meant for the granularity to be at the "request" level. So, it is a
(lazy) list of requests. I had conceived of the implementation
reading/parsing the entire request.

The lazy-ness is really in taking advantage of patterns for list
processing. Perhaps I didn't give an example like:
	(define list-of-http-transactions (mod_lisp some-port-listener))
	(for-each handle-request list-of-http-transactions)

As I looked at doing a lazy-list implementation, I was blocked by the
fact that I can't do the example I just gave. The standard (and library)
functions aren't generic for delay'd values. Thus, if I created a
lazy-list, I couldn't use it with libraries (even the basic for-each/map
functions) and neither could client code. By providing a lazy-list, I
would force client-code to use a separate library of lazy-list functions.

-- Alan Grover awgrover@mail.msen.com +1.734.476.0969

_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user