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 [EMAIL PROTECTED] +1.734.476.0969
_______________________________________________
Guile-user mailing list
Guile-user@gnu.org
http://lists.gnu.org/mailman/listinfo/guile-user
