From mboxrd@z Thu Jan 1 00:00:00 1970 Path: news.gmane.org!not-for-mail From: Alan Grover Newsgroups: gmane.lisp.guile.user Subject: Re: mod_lisp for guile Date: Mon, 05 Dec 2005 12:21:07 -0500 Message-ID: <43947703.9030401@mail.msen.com> References: <4329AE76.4000606@mail.msen.com> <871x3ohmv0.fsf@ossau.uklinux.net> <432ECF41.4080500@mail.msen.com> <87br2ozqul.fsf@ossau.uklinux.net> <432F80F2.4080605@mail.msen.com> <87oe3xgopj.fsf@ossau.uklinux.net> NNTP-Posting-Host: main.gmane.org Mime-Version: 1.0 Content-Type: text/plain; charset=ISO-8859-1 Content-Transfer-Encoding: 7bit X-Trace: sea.gmane.org 1133804376 2506 80.91.229.2 (5 Dec 2005 17:39:36 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 5 Dec 2005 17:39:36 +0000 (UTC) Cc: guile-user@gnu.org Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Dec 05 18:39:33 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EjKIt-0004lv-0K for guile-user@m.gmane.org; Mon, 05 Dec 2005 18:39:07 +0100 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EjKJ1-0007q0-T1 for guile-user@m.gmane.org; Mon, 05 Dec 2005 12:39:15 -0500 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EjJz8-0002lj-Qo for guile-user@gnu.org; Mon, 05 Dec 2005 12:18:42 -0500 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EjJz7-0002l6-Lx for guile-user@gnu.org; Mon, 05 Dec 2005 12:18:42 -0500 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EjJz7-0002kw-EI for guile-user@gnu.org; Mon, 05 Dec 2005 12:18:41 -0500 Original-Received: from [148.59.80.48] (helo=ww8.msen.com) by monty-python.gnu.org with esmtp (TLS-1.0:DHE_RSA_3DES_EDE_CBC_SHA:24) (Exim 4.34) id 1EjJze-0003DT-6I for guile-user@gnu.org; Mon, 05 Dec 2005 12:19:14 -0500 X-Sent-To: Original-Received: from [192.168.1.221] (pool-151-196-6-194.balt.east.verizon.net [151.196.6.194]) (authenticated bits=0) by ww8.msen.com (8.13.4/8.13.4) with ESMTP id jB5HIR08066509 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT) for ; Mon, 5 Dec 2005 12:18:28 -0500 (EST) (envelope-from awgrover@mail.msen.com) User-Agent: Mozilla Thunderbird 1.0.6 (X11/20050716) X-Accept-Language: en-us, en In-Reply-To: <87oe3xgopj.fsf@ossau.uklinux.net> Received-SPF: Pass (sender authenticated); receiver=(null); client-ip=151.196.6.194; envelope-from= Received-SPF: Pass (sender authenticated); receiver=(null); client-ip=151.196.6.194; helo=[192.168.1.221] X-Milter: Spamilter (Reciever: ww8.msen.com; Sender-ip: 151.196.6.194; Sender-helo: [192.168.1.221]; ) X-BeenThere: guile-user@gnu.org X-Mailman-Version: 2.1.5 Precedence: list List-Id: General Guile related discussions List-Unsubscribe: , List-Archive: List-Post: List-Help: List-Subscribe: , Original-Sender: guile-user-bounces+guile-user=m.gmane.org@gnu.org Errors-To: guile-user-bounces+guile-user=m.gmane.org@gnu.org Xref: news.gmane.org gmane.lisp.guile.user:4976 Archived-At: 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