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, 19 Sep 2005 10:46:25 -0400 Message-ID: <432ECF41.4080500@mail.msen.com> References: <4329AE76.4000606@mail.msen.com> <871x3ohmv0.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 1127142169 11087 80.91.229.2 (19 Sep 2005 15:02:49 GMT) X-Complaints-To: usenet@sea.gmane.org NNTP-Posting-Date: Mon, 19 Sep 2005 15:02:49 +0000 (UTC) Cc: Neil Jerram Original-X-From: guile-user-bounces+guile-user=m.gmane.org@gnu.org Mon Sep 19 17:02:39 2005 Return-path: Original-Received: from lists.gnu.org ([199.232.76.165]) by ciao.gmane.org with esmtp (Exim 4.43) id 1EHN7V-0008HM-Lv for guile-user@m.gmane.org; Mon, 19 Sep 2005 16:59:50 +0200 Original-Received: from localhost ([127.0.0.1] helo=lists.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EHN7V-00047h-66 for guile-user@m.gmane.org; Mon, 19 Sep 2005 10:59:49 -0400 Original-Received: from mailman by lists.gnu.org with tmda-scanned (Exim 4.43) id 1EHN4Q-0002y7-Vj for guile-user@gnu.org; Mon, 19 Sep 2005 10:56:42 -0400 Original-Received: from exim by lists.gnu.org with spam-scanned (Exim 4.43) id 1EHN4B-0002pW-3a for guile-user@gnu.org; Mon, 19 Sep 2005 10:56:25 -0400 Original-Received: from [199.232.76.173] (helo=monty-python.gnu.org) by lists.gnu.org with esmtp (Exim 4.43) id 1EHN49-0002lE-P2 for guile-user@gnu.org; Mon, 19 Sep 2005 10:56:21 -0400 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 1EHMub-0000FC-Mg for guile-user@gnu.org; Mon, 19 Sep 2005 10:46:29 -0400 X-Sent-To: guile-user@gnu.org Original-Received: from [192.168.1.220] (pool-151-196-115-140.balt.east.verizon.net [151.196.115.140]) (authenticated bits=0) by ww8.msen.com (8.13.4/8.13.4) with ESMTP id j8JEkQig014357 (version=TLSv1/SSLv3 cipher=DHE-RSA-AES256-SHA bits=256 verify=NOT); Mon, 19 Sep 2005 10:46:26 -0400 (EDT) (envelope-from awgrover@mail.msen.com) User-Agent: Mozilla Thunderbird 1.0.2 (X11/20050317) X-Accept-Language: en-us, en Original-To: guile-user@gnu.org In-Reply-To: <871x3ohmv0.fsf@ossau.uklinux.net> X-Milter: Spamilter (Reciever: ww8.msen.com; Sender-ip: 151.196.115.140; Sender-helo: [192.168.1.220]; ) 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:4750 Archived-At: Neil Jerram wrote: > Alan Grover writes: >>* Should I remove the thread-creation stuff and stick simply to mod_lisp >>protocol? > > > I don't understand what the mod_lisp protocol is, so can't really > comment. I'm interested in the architecture though - can you describe > it (or point me to reference)? Mod_lisp is a module for the Apache web-server. Via a simple configuration, you can have Apache "forward" a request to a separate process. The mod_lisp protocol is very simple. The mod_lisp home is: http://www.fractalconcept.com/asp/tC2/sdataQvrZSvEqz7EuDM==/uC2sdataQuvY9x3g$ecX So, instead of writing a HTTP server, you write a mod_lisp server which is simpler. You can take advantage of all the features of Apache (ssl, filtering, rewriting, access control, aliasing, etc.). Or, instead of writing your web-application as a CGI, your mod-lisp server is a separate process that is always running. Thus, you avoid the delay of starting a process for each CGI, instead starting it once as a daemon. You could use threads to handle the requests, possibly reducing resource usage, and allowing simple inter-thread communication, but requiring consideration of races/locks. Forking could also be used. >>* Should I provide an interface to integrate with TTN's www-guile? > > > How would that help? (Genuine question.) Several people have produced modules/code to help handle the CGI interface. TTN's, for example, parses the environment variables to produce a scheme friendly interface, and parses the query-string. Such modules have done the work to be standards compliant/complete. So, I'd have to figure a clever way for TTN's www-guile to see the mod-lisp data, or propose a patch that integrates with mod-lisp. >>* How bad is the user-interface? > > > Do you mean the programming interface? (By UI I'd normally understand > something like a window or a command line, and AFAICS mod_lisp doesn't > have either of these.) Bit of a slip there. Literally the "user's interface", the user being the programmer. On a good day, I would have said API. >>* What do you think of providing a lazy-list of requests, rather than >>the current technique of passing control to a >>blocking-looping-function? > > > Don't understand enough yet to know! Please explain further. The interface in the first release is a function that loops, calling your function for each request. So, it kind of takes over. It occurred to me that there might be more polite ways of working. At the very least, there should be mechanisms that impose the least policy. So, I'm going to work on (some of) the following interfaces: * (f port) -> headers-as-alist, does nothing else * (f port header-constructor) -> calls (header-constructor k v) for each header, does nothing else (maybe like fold?) * (f port) -> lazy list of (k v), suitable for whatever map/fold you want to do. * (f port) -> (headers content-length), convenience for post-data * Same, plus the header-constructor * (f port ...) -> returns a lazy list of something like (headers port), (one element for each request, blocking). * Perhaps versions of the above that return something like (request-header-port ; returns pairs (k v) till '()/#f request-content-port ; returns content part till eof-object response-header-port ; takes only pairs (k v) response-content-port) ; typical HTML body Where request-content-port would only return up-to content-length bytes, and response-content-port constructs the content-length header if needed. Lazy-lists (see "delay" and "force") are things that act like a list, but where the next-element isn't calculated until you "look" at it (this is only one kind of lazy-list, but close enough). So, assuming I provided lazy-mod-lisp: (define lazy-results (lazy-mod-lisp socket-port)) (pair? lazy-results) ; -> #t. maybe not, I'd have to check ; actually does the work to figure out first mod-lisp request. could block! (define first (car lazy-results)) ; might need "force" ; Handle the request (and to loop here) (my-handle-request first) (set! lazy-results (cdr lazy-results)) ; never blocks! (set! first (car lazy-results)) ; might need "force" ; Loop back to my-handle-request (till '() ) Or, ; Could/will block, waiting for each mod-lisp request (for-each my-handle-request lazy-results) You might have to call "force" on "first", I'd have to check (see forthcoming version of my mod-lisp for guile/scheme). >>* Do you want to see a SRFI that provides _just_ the mod_lisp >>protocol? > > > Presumably you mean a SRFI defining a common Scheme API that people > could use to write code that plugs into your mod_lisp engine? (I > guess I'm missing the architecture again here.) Right, convenient API to the scheme side of the protocol. _______________________________________________ Guile-user mailing list Guile-user@gnu.org http://lists.gnu.org/mailman/listinfo/guile-user