Hi,
I've attached patches for both Araneida and TBNL to this message. Sorry for the cross-posting but there is some co-ordination required here and I thought this would be a good way to do it.
I've included this message the text from a README file that is part of the tgz file I've attached.
Unfortunately there is a really *nasty* bug with the browser->tbnl connection -- it consumes about 250k of memory for every access. I cannot see the problem, and I'm looking for help :-)
It appears to be completely stable for browser->araneida->tbnl (tested for 100's of thousands of hits).
I don't know how the tbnl-araneida package with the example should be distributed.
I'm sure this description is too brief, I'll answer what questions I can.
I hope you find this useful.
Cheers, Bob
--------
Some changes have been made to allow TBNL to be used with Araneida. In particular, it is now possible to use Araneida as a server to TBNL handlers and it is possible to send HTTP requests directly to the TBNL socket (in effect by-passing Araneida).
This means that the following connections are possible *simultaneously*
browser->apache->araneida browser->apache->araneida->tbnl (NEW) browser->apache->mod_lisp->tbnl browser->araneida browser->araneida->tbnl (NEW) browser->tbnl (NEW)
There is a package, tbnl-araneida, that shows how this works.
In Summary...
To connect directly to TBNL, all that is required is that araneida is compiled and loaded *before* tbnl is compiled and loaded. (There is conditionally compiled code in TBNL).
To connect to TBNL through Araneida, use the the Araneida handler -- tbnl-araneida-handler -- provided for this purpose.
Note that in both cases the TBNL *dispatch-table* must be set up as you normally would when using TBNL. The sense of the installed Araneida handler changes slightly to a url prefix mapper to TBNL (which further refines the request using the *dispatch-table*).
--------
---- Bob Hutchison -- blogs at http://www.recursive.ca/hutch/ Recursive Design Inc. -- http://www.recursive.ca/
Hi!
On Mon, 14 Mar 2005 08:22:00 -0500, Bob Hutchison hutch@recursive.ca wrote:
I've attached patches for both Araneida and TBNL to this message. Sorry for the cross-posting but there is some co-ordination required here and I thought this would be a good way to do it.
Thanks. I've released a new version of TBNL (0.4.0) which includes your patches and some initial documentation on how to use it - please check.
It worked for me with LispWorks and AllegroCL but I get an error with CMUCL:
No matching method for the generic function #<STANDARD-GENERIC-FUNCTION ARANEIDA::HTTP-LISTENER-THREADS (1) {5964F471}>, when called with arguments (#<ARANEIDA:SERVE-EVENT-REVERSE-PROXY-LISTENER {593B3BC5}>). [Condition of type PCL::NO-APPLICABLE-METHOD-ERROR]
Unfortunately there is a really *nasty* bug with the browser->tbnl connection -- it consumes about 250k of memory for every access. I cannot see the problem, and I'm looking for help :-)
How does one test the browser->tbnl part?
I don't know how the tbnl-araneida package with the example should be distributed.
I've modified it and added it to the TBNL distribution. It'll now basically show the same pages the Apache/mod_lisp demo shows. Hope that's OK for you.
Thanks again, Edi.
On Mar 14, 2005, at 4:50 PM, Edi Weitz wrote:
Hi!
On Mon, 14 Mar 2005 08:22:00 -0500, Bob Hutchison hutch@recursive.ca wrote:
I've attached patches for both Araneida and TBNL to this message. Sorry for the cross-posting but there is some co-ordination required here and I thought this would be a good way to do it.
Thanks. I've released a new version of TBNL (0.4.0) which includes your patches and some initial documentation on how to use it - please check.
I've downloaded it and installed. Encountered a little problem. In araneida-test it seems that the setq of the *dispatch-table* has to be a top level form the way the path to the fz.jpg file is written. If you move it out of the setup code and onto the top level then compile and load (in Lispworks) it will work... at least for me.
It worked for me with LispWorks and AllegroCL but I get an error with CMUCL:
No matching method for the generic function #<STANDARD-GENERIC-FUNCTION ARANEIDA::HTTP-LISTENER-THREADS (1) {5964F471}>, when called with arguments (#<ARANEIDA:SERVE-EVENT-REVERSE-PROXY-LISTENER {593B3BC5}>). [Condition of type PCL::NO-APPLICABLE-METHOD-ERROR]
I think I might know what this is. I can't run CMUCL but I'll have a look.
Unfortunately there is a really *nasty* bug with the browser->tbnl connection -- it consumes about 250k of memory for every access. I cannot see the problem, and I'm looking for help :-)
How does one test the browser->tbnl part?
Hit port 3000 from your browser, for example http://localhost:3000/tbnl-araneida in my setup. You have to apply the patches to Araneida 0.9 of course, and *make* *sure* you recompile and use ASDF to load it.
I don't know how the tbnl-araneida package with the example should be distributed.
I've modified it and added it to the TBNL distribution. It'll now basically show the same pages the Apache/mod_lisp demo shows. Hope that's OK for you.
Fine by me. Thanks for doing this so quickly.
Cheers, Bob
Thanks again, Edi.
---- Bob Hutchison -- blogs at http://www.recursive.ca/hutch/ Recursive Design Inc. -- http://www.recursive.ca/
On Mon, 14 Mar 2005 19:30:48 -0500, Bob Hutchison hutch@recursive.ca wrote:
Encountered a little problem. In araneida-test it seems that the setq of the *dispatch-table* has to be a top level form the way the path to the fz.jpg file is written. If you move it out of the setup code and onto the top level then compile and load (in Lispworks) it will work... at least for me.
Hmm, that should be irrelevant as I had the SETQ disabled with #+(or). The *DISPATCH-TABLE* is supposed to be set by the top-level form in test.lisp. You did load the test as described here
http://weitz.de/tbnl/#araneida,
didn't you?
Cheers, Edi.
On Mar 14, 2005, at 8:36 PM, Edi Weitz wrote:
On Mon, 14 Mar 2005 19:30:48 -0500, Bob Hutchison hutch@recursive.ca wrote:
Encountered a little problem. In araneida-test it seems that the setq of the *dispatch-table* has to be a top level form the way the path to the fz.jpg file is written. If you move it out of the setup code and onto the top level then compile and load (in Lispworks) it will work... at least for me.
Hmm, that should be irrelevant as I had the SETQ disabled with #+(or). The *DISPATCH-TABLE* is supposed to be set by the top-level form in test.lisp. You did load the test as described here
http://weitz.de/tbnl/#araneida,
didn't you?
I guess the trouble started when I restarted it.
Cheers, Edi.
---- Bob Hutchison -- blogs at http://www.recursive.ca/hutch/ Recursive Design Inc. -- http://www.recursive.ca/
On Tue, 15 Mar 2005 07:08:34 -0500, Bob Hutchison hutch@recursive.ca wrote:
I guess the trouble started when I restarted it.
You did (STOP) and then (START) again? And what happened? Is that a reproducible problem?
Thanks, Edi.
On Mar 15, 2005, at 7:13 AM, Edi Weitz wrote:
On Tue, 15 Mar 2005 07:08:34 -0500, Bob Hutchison hutch@recursive.ca wrote:
I guess the trouble started when I restarted it.
You did (STOP) and then (START) again? And what happened? Is that a reproducible problem?
If I start it the way you document the startup of LW fails because multiprocessing isn't running yet. So I've got to run start later.
The start that I wrote, attempts to stop first.
The other thing that I wanted to be able to do is add handlers without restarting LW, that takes a long time in my configuration (a couple of minutes).
Cheers, Bob
Thanks, Edi.
---- Bob Hutchison -- blogs at http://www.recursive.ca/hutch/ Recursive Design Inc. -- http://www.recursive.ca/
On Tue, 15 Mar 2005 07:58:45 -0500, Bob Hutchison hutch@recursive.ca wrote:
If I start it the way you document the startup of LW fails because multiprocessing isn't running yet. So I've got to run start later.
I've got
(mp:initialize-multiprocessing)
at the end of my ~/.lispworks file. But I don't understand how something I describe in the TBNL docs can cause LW startup to fail. I was assuming that you've already started your Lisp before you load Araneida and TBNL. What exactly do you mean?
The other thing that I wanted to be able to do is add handlers without restarting LW, that takes a long time in my configuration (a couple of minutes).
You should be able to add/remove handlers just by modifying *DISPATCH-TABLE*, no need to stop or restart anything.
Cheers, Edi.
On Mar 15, 2005, at 10:17 AM, Edi Weitz wrote:
On Tue, 15 Mar 2005 07:58:45 -0500, Bob Hutchison hutch@recursive.ca wrote:
If I start it the way you document the startup of LW fails because multiprocessing isn't running yet. So I've got to run start later.
I've got
(mp:initialize-multiprocessing)
at the end of my ~/.lispworks file. But I don't understand how something I describe in the TBNL docs can cause LW startup to fail. I was assuming that you've already started your Lisp before you load Araneida and TBNL. What exactly do you mean?
I load it in my .lispworks file... which is why I'm having problems I think.
The other thing that I wanted to be able to do is add handlers without restarting LW, that takes a long time in my configuration (a couple of minutes).
You should be able to add/remove handlers just by modifying *DISPATCH-TABLE*, no need to stop or restart anything.
Cheers, Edi.
---- Bob Hutchison -- blogs at http://www.recursive.ca/hutch/ Recursive Design Inc. -- http://www.recursive.ca/
On Mon, 14 Mar 2005 19:30:48 -0500, Bob Hutchison hutch@recursive.ca wrote:
Hit port 3000 from your browser, for example http://localhost:3000/tbnl-araneida in my setup. You have to apply the patches to Araneida 0.9 of course, and *make* *sure* you recompile and use ASDF to load it.
Hmm, I can't seem to reproduce the memory leaks you reported. I've reloaded the info.html page from the test suite about 200 times and the output of (ROOM) is stable. LW 4.4.0 on WinXP.
BTW, how exactly does this direct connection to port 3000 work? Araneida isn't used at all and all the communication with the browser is directly handled by TBNL? (Yeah, I could look it up myself but it's 3 a.m. here and I'm tired... :)
Cheers, Edi.
On Mar 14, 2005, at 9:19 PM, Edi Weitz wrote:
On Mon, 14 Mar 2005 19:30:48 -0500, Bob Hutchison hutch@recursive.ca wrote:
Hit port 3000 from your browser, for example http://localhost:3000/tbnl-araneida in my setup. You have to apply the patches to Araneida 0.9 of course, and *make* *sure* you recompile and use ASDF to load it.
Hmm, I can't seem to reproduce the memory leaks you reported. I've reloaded the info.html page from the test suite about 200 times and the output of (ROOM) is stable. LW 4.4.0 on WinXP.
I'm using LW 4.4.0 on OS/X
I ran the following commands
<measure> ab -n 200 -c 10 http://localhost:3000/tbnl-araneida | tee results.ab.3000 ab -n 200 -c 10 http://localhost:3000/tbnl-araneida | tee results.ab.3000 <measure> ab -n 1400 -c 10 http://localhost:3000/tbnl-araneida | tee results.ab.3000 <measure>
Then using the process monitor saw the following growth (in MB): before after 400 after 1400 real 70.74 77.86 89.82 virtual 249.16 461.91 969.97
(room) before Generation 0: Total Size 14505K, Allocated 9137K, Free 5335K Generation 1: Total Size 18806K, Allocated 3796K, Free 14977K Generation 2: Total Size 16196K, Allocated 11197K, Free 4977K Generation 3: Total Size 10631K, Allocated 10518K, Free 67K
(room) after 400 Generation 0: Total Size 14505K, Allocated 1964K, Free 12509K Generation 1: Total Size 18934K, Allocated 3422K, Free 15479K Generation 2: Total Size 18756K, Allocated 11816K, Free 6914K Generation 3: Total Size 10631K, Allocated 10518K, Free 67K
(room) after 1400 Generation 0: Total Size 14505K, Allocated 1778K, Free 12694K Generation 1: Total Size 19062K, Allocated 3454K, Free 15575K Generation 2: Total Size 25796K, Allocated 11816K, Free 13954K Generation 3: Total Size 10631K, Allocated 10518K, Free 67K
BTW, how exactly does this direct connection to port 3000 work? Araneida isn't used at all and all the communication with the browser is directly handled by TBNL? (Yeah, I could look it up myself but it's 3 a.m. here and I'm tired... :)
I changed get-apache-command to (unroll the first iteration of the loop and so) read the first line and check to see if it contains a space. If the line came from mod_lisp it will not have a space in it. If it has a space, we know it wasn't mod_lisp so assume that we've got a direct HTTP request. When handling HTTP, call the read-request-from-stream/tbnl function (just above get-apache-command in modlisp.lisp). This sets up the new araneida::*standard-araneida* special variable (to nil) and calls araneida::read-request-from-stream/guts which is a new entry point in Araneida that I added by breaking up the previous function (read-request-from-stream). It then adds a couple of headers (url, content-stream, and server-ip-port) that TBNL seems to want. It then calls process-apache-command and returns.
Cheers, Bob
Cheers, Edi.
---- Bob Hutchison -- blogs at http://www.recursive.ca/hutch/ Recursive Design Inc. -- http://www.recursive.ca/
On Tue, 15 Mar 2005 07:34:29 -0500, Bob Hutchison hutch@recursive.ca wrote:
I changed get-apache-command to (unroll the first iteration of the loop and so) read the first line and check to see if it contains a space. If the line came from mod_lisp it will not have a space in it. If it has a space, we know it wasn't mod_lisp so assume that we've got a direct HTTP request. When handling HTTP, call the read-request-from-stream/tbnl function (just above get-apache-command in modlisp.lisp). This sets up the new araneida::*standard-araneida* special variable (to nil) and calls araneida::read-request-from-stream/guts which is a new entry point in Araneida that I added by breaking up the previous function (read-request-from-stream). It then adds a couple of headers (url, content-stream, and server-ip-port) that TBNL seems to want. It then calls process-apache-command and returns.
So this should basically work without Araneida being there at all, right? Or is Araneida involved in sending the reply back to the browser?
On Mar 15, 2005, at 7:39 AM, Edi Weitz wrote:
On Tue, 15 Mar 2005 07:34:29 -0500, Bob Hutchison hutch@recursive.ca wrote:
I changed get-apache-command to (unroll the first iteration of the loop and so) read the first line and check to see if it contains a space. If the line came from mod_lisp it will not have a space in it. If it has a space, we know it wasn't mod_lisp so assume that we've got a direct HTTP request. When handling HTTP, call the read-request-from-stream/tbnl function (just above get-apache-command in modlisp.lisp). This sets up the new araneida::*standard-araneida* special variable (to nil) and calls araneida::read-request-from-stream/guts which is a new entry point in Araneida that I added by breaking up the previous function (read-request-from-stream). It then adds a couple of headers (url, content-stream, and server-ip-port) that TBNL seems to want. It then calls process-apache-command and returns.
So this should basically work without Araneida being there at all, right? Or is Araneida involved in sending the reply back to the browser?
Other than it uses the daemon.lisp code from Araneida to parse headers on the way in, it does not need Araneida. I had considered writing an HTTP header parser specifically for TBNL but I thought that modifying the daemon.lisp code would be quicker. It isn't hard writing HTTP header parsers, you only have to watch for multi-line headers.
I had to modify TBNL to write HTTP headers on the way out in order to make it work with Araneida as a front end. So, saying this explicitly, TBNL is writing the HTTP response directly to the socket. (Though I have not tested this with redirect or require-authorization -- I had modified send-output and write-header-line to accomplish this).
I didn't do anything about logging for either the stand-alone or with-araneida versions.
The next logical step is to write an HTTP header parser for TBNL (or negotiate with the Araneida folks to use their code).
---- Bob Hutchison -- blogs at http://www.recursive.ca/hutch/ Recursive Design Inc. -- http://www.recursive.ca/
On Tue, 15 Mar 2005 07:56:35 -0500, Bob Hutchison hutch@recursive.ca wrote:
Other than it uses the daemon.lisp code from Araneida to parse headers on the way in, it does not need Araneida. I had considered writing an HTTP header parser specifically for TBNL but I thought that modifying the daemon.lisp code would be quicker. It isn't hard writing HTTP header parsers, you only have to watch for multi-line headers.
I had to modify TBNL to write HTTP headers on the way out in order to make it work with Araneida as a front end. So, saying this explicitly, TBNL is writing the HTTP response directly to the socket. (Though I have not tested this with redirect or require-authorization -- I had modified send-output and write-header-line to accomplish this).
OK, thanks for the info. I'll try to do some more tests and add more documentation about this feature.
I didn't do anything about logging for either the stand-alone or with-araneida versions.
Maybe we should address this in one of the future releases. Kind of embarassing if you send your logging data back to the client as a header... :)
The next logical step is to write an HTTP header parser for TBNL (or negotiate with the Araneida folks to use their code).
Can't we just steal it? Araneida also has a BSD license.
Cheers, Edi.
"Edi Weitz" edi@agharta.de wrote:
On Tue, 15 Mar 2005 07:56:35 -0500, Bob Hutchison hutch@recursive.ca
wrote:
The next logical step is to write an HTTP header parser for TBNL (or negotiate with the Araneida folks to use their code).
Can't we just steal it? Araneida also has a BSD license.
Heh! Maybe "borrowing" is more politically correct than "stealing" ;-) As long as the copyright is left it should be OK IMO. (I've put iterate in cl-pdf and I will probably put Zach Beane's zlib in it as well)
Marc
On Tue, 15 Mar 2005 16:31:17 +0100, "Marc Battyani" marc.battyani@fractalconcept.com wrote:
Heh! Maybe "borrowing" is more politically correct than "stealing" ;-)
Hehe... :)
As long as the copyright is left it should be OK IMO. (I've put iterate in cl-pdf and I will probably put Zach Beane's zlib in it as well)
Yes, I already wanted to mention that lib to you. One more step towards the "get rid of all FFI calls" direction... :)
Cheers, Edi.
"Edi Weitz" edi@agharta.de wrote:
On Tue, 15 Mar 2005 16:31:17 +0100, "Marc Battyani"
marc.battyani@fractalconcept.com wrote:
iterate in cl-pdf and I will probably put Zach Beane's zlib in it as well)
Yes, I already wanted to mention that lib to you. One more step towards the "get rid of all FFI calls" direction... :)
Yes, it's very interesting. The zlib FFI has been the major portability problem for cl-pdf. I'm already in contact with Zach about this and I will put it in cl-pdf as soon as it works on the major implementations.
Marc
On Mar 15, 2005, at 10:48 AM, Edi Weitz wrote:
On Tue, 15 Mar 2005 16:31:17 +0100, "Marc Battyani" marc.battyani@fractalconcept.com wrote:
Heh! Maybe "borrowing" is more politically correct than "stealing" ;-)
Hehe... :)
As long as the copyright is left it should be OK IMO. (I've put iterate in cl-pdf and I will probably put Zach Beane's zlib in it as well)
Yes, I already wanted to mention that lib to you. One more step towards the "get rid of all FFI calls" direction... :)
Actually, I wanted to mention that library to *you* Edi. What do you think about supporting gzip (and/or deflate) encoding? I was going to add it to TBNL -- the application I am working on used to be in Java and gzip encoding had an enormous (positive) impact on performance. If somebody else is already doing this then I won't worry about it.
Marc, what happens with mod_lisp if an gzip encoded body is returned? I think you must just pass it along, but that part is written in C and, well, I'd rather ask than look for myself :-)
Cheers, Bob
Cheers, Edi.
---- Bob Hutchison -- blogs at http://www.recursive.ca/hutch/ Recursive Design Inc. -- http://www.recursive.ca/
On 2005-03-16 07:23:42, Bob Hutchison wrote:
Actually, I wanted to mention that library to *you* Edi. What do you think about supporting gzip (and/or deflate) encoding? I was going to
Yesterday on #lisp:
17:43 < stesch> OK, now for any "Accept-Encoding:.*gzip" one could run Xach's zlib thing. Who implements this for TBNL?
(No answers. :-)
On Mar 16, 2005, at 7:36 AM, Stefan Scholl wrote:
On 2005-03-16 07:23:42, Bob Hutchison wrote:
Actually, I wanted to mention that library to *you* Edi. What do you think about supporting gzip (and/or deflate) encoding? I was going to
Yesterday on #lisp:
17:43 < stesch> OK, now for any "Accept-Encoding:.*gzip" one could run Xach's zlib thing. Who implements this for TBNL?
(No answers. :-)
What's #lisp?
I can do it easily enough I think. If I can't get it done in the next couple of days it will be a few weeks (I have a vacation scheduled and I -- voluntarily -- subject myself to computer and internet withdrawal for the duration -- for some reason I imagine that this somehow proves to my wife that I'm not really an addict :-)
Cheers, Bob
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
---- Bob Hutchison -- blogs at http://www.recursive.ca/hutch/ Recursive Design Inc. -- http://www.recursive.ca/
On 2005-03-16 07:43:33, Bob Hutchison wrote:
On Mar 16, 2005, at 7:36 AM, Stefan Scholl wrote:
Yesterday on #lisp: 17:43 < stesch> OK, now for any "Accept-Encoding:.*gzip" one could run Xach's zlib thing. Who implements this for TBNL?
What's #lisp?
IRC channel #lisp on the IRC network freenode. http://www.cliki.net/IRC
I can do it easily enough I think. If I can't get it done in the next
Should be easy. I would look for the documentation of mod_gzip to see what headers have to be set and questioned.
AFAIK incoming "Accept-Encoding" must be checked for "gzip" and in the response header "Vary: Accept-Encoding" and "Content-Encoding: gzip" must be set. (I've just read the request and response header for a website that uses mod_gzip.)
Err, is it "gzip" or "deflate"?
for the duration -- for some reason I imagine that this somehow proves to my wife that I'm not really an addict :-)
I can quit any time I want! :-)
On Wed, 16 Mar 2005 07:23:42 -0500, Bob Hutchison hutch@recursive.ca wrote:
Actually, I wanted to mention that library to *you* Edi. What do you think about supporting gzip (and/or deflate) encoding? I was going to add it to TBNL -- the application I am working on used to be in Java and gzip encoding had an enormous (positive) impact on performance. If somebody else is already doing this then I won't worry about it.
Hmm, since I've always used Apache/mod_lisp in front of TBNL I also used mod_gzip which works quite well. I don't think that adding this to TBNL is a good idea because it'll complicate things and is already available in the backend. What do others think?
Cheers, Edi.
"Edi Weitz" edi@agharta.de wrote:
On Wed, 16 Mar 2005 07:23:42 -0500, Bob Hutchison hutch@recursive.ca
wrote:
Actually, I wanted to mention that library to *you* Edi. What do you think about supporting gzip (and/or deflate) encoding? I was going to add it to TBNL -- the application I am working on used to be in Java and gzip encoding had an enormous (positive) impact on performance. If somebody else is already doing this then I won't worry about it.
Hmm, since I've always used Apache/mod_lisp in front of TBNL I also used mod_gzip which works quite well. I don't think that adding this to TBNL is a good idea because it'll complicate things and is already available in the backend. What do others think?
I also think that trying to duplicate Apache is a waste of time. Having a lightweight standalone front-end for demos or small apps is a good idea but using it for real production applications seems a bad idea.
Marc
"Bob Hutchison" hutch@recursive.ca wrote:
Actually, I wanted to mention that library to *you* Edi. What do you think about supporting gzip (and/or deflate) encoding? I was going to add it to TBNL -- the application I am working on used to be in Java and gzip encoding had an enormous (positive) impact on performance. If somebody else is already doing this then I won't worry about it.
Marc, what happens with mod_lisp if an gzip encoded body is returned? I think you must just pass it along, but that part is written in C and, well, I'd rather ask than look for myself :-)
You can pass what you want to mod_lisp as long as you give the correct content-length and headers. But If you use Apache you should better use mod_gzip. I don't think it's a good idea to try to compete with Apache for a production server. Even paserve and Areneida servers generally hide behind Apache for real production use. It's just that they do it the wrong way with mod_proxy rather than mod_lisp. ;-)
Marc
On Mar 15, 2005, at 10:11 AM, Edi Weitz wrote:
On Tue, 15 Mar 2005 07:56:35 -0500, Bob Hutchison hutch@recursive.ca wrote:
Other than it uses the daemon.lisp code from Araneida to parse headers on the way in, it does not need Araneida. I had considered writing an HTTP header parser specifically for TBNL but I thought that modifying the daemon.lisp code would be quicker. It isn't hard writing HTTP header parsers, you only have to watch for multi-line headers.
I had to modify TBNL to write HTTP headers on the way out in order to make it work with Araneida as a front end. So, saying this explicitly, TBNL is writing the HTTP response directly to the socket. (Though I have not tested this with redirect or require-authorization -- I had modified send-output and write-header-line to accomplish this).
OK, thanks for the info. I'll try to do some more tests and add more documentation about this feature.
I didn't do anything about logging for either the stand-alone or with-araneida versions.
Maybe we should address this in one of the future releases. Kind of embarassing if you send your logging data back to the client as a header... :)
Yes, I agree :-)
The next logical step is to write an HTTP header parser for TBNL (or negotiate with the Araneida folks to use their code).
Can't we just steal it? Araneida also has a BSD license.
I've just written a little parser that I am trying out. What format do you expect the header 'keys' to be in? Araneida has them as symbols, I think TBNL wants strings... what about case sensitivity?
Cheers, Bob
Cheers, Edi.
---- Bob Hutchison -- blogs at http://www.recursive.ca/hutch/ Recursive Design Inc. -- http://www.recursive.ca/
"Bob Hutchison" hutch@recursive.ca wrote:
I've just written a little parser that I am trying out. What format do you expect the header 'keys' to be in? Araneida has them as symbols, I think TBNL wants strings... what about case sensitivity?
Just keep mod_lisp compatible headers (the strings in the alist)) so that it can be interchangeable with mod_lisp. It's case sensitive normally.
Marc
On Mar 15, 2005, at 12:18 PM, Marc Battyani wrote:
"Bob Hutchison" hutch@recursive.ca wrote:
I've just written a little parser that I am trying out. What format do you expect the header 'keys' to be in? Araneida has them as symbols, I think TBNL wants strings... what about case sensitivity?
Just keep mod_lisp compatible headers (the strings in the alist)) so that it can be interchangeable with mod_lisp. It's case sensitive normally.
So now is the time to ask I think :-) Marc, what headers are you adding in mod_lisp? Is this documented someplace? I'm already adding a few headers that TBNL needs, it would be very easy to add more.
Edi, is there a recommended way to find headers in TBNL? I can't find it, but I might be staring right at it and still not see it -- this has happened before :-) If there isn't, maybe this would be a good time to add one?
Oh, same question for you Edi, what headers do you need to be present that may not be supplied by the user's browser?
Cheers, Bob
Marc
---- Bob Hutchison -- blogs at http://www.recursive.ca/hutch/ Recursive Design Inc. -- http://www.recursive.ca/
On Wed, 16 Mar 2005 07:33:58 -0500, Bob Hutchison hutch@recursive.ca wrote:
Oh, same question for you Edi, what headers do you need to be present that may not be supplied by the user's browser?
I've begun to prepare a new release which includes your patch and a new logging facility. This new release will also include updated docs and when I'm finished doing that I can answer this question in more detail.
Unfortunately, I have to work for money now, so the release will have to wait until tonight or so... :)
Cheers, Edi.
"Bob Hutchison" hutch@recursive.ca wrote:
So now is the time to ask I think :-) Marc, what headers are you adding in mod_lisp? Is this documented someplace? I'm already adding a few headers that TBNL needs, it would be very easy to add more.
Basically it's the HTTP headers that are in the request. So what you should do is to add all the headers you parse to the alist so that the application can do whatever it wants with it. You can also add some ones ot comming from the browser, like the client IP for instance.
Marc
On 2005-03-15 11:34:44, Bob Hutchison wrote:
On Mar 15, 2005, at 10:11 AM, Edi Weitz wrote:
Maybe we should address this in one of the future releases. Kind of embarassing if you send your logging data back to the client as a header... :)
Yes, I agree :-)
I haven't read all the recent patches. Is this problem addressed?
I'd say let the user supply his own logging function which gets all the "Log*" lines TBNL sends to Araneida or standalone-thingy.
*LOG-FUNCTION* or something.
For presentation nobody gets strange header lines. And if you really have to debug you can use a simple function to write in a logfile or use CL-SYSLOG for a more sophisticated way.
On Mar 16, 2005, at 7:46 AM, Stefan Scholl wrote:
On 2005-03-15 11:34:44, Bob Hutchison wrote:
On Mar 15, 2005, at 10:11 AM, Edi Weitz wrote:
Maybe we should address this in one of the future releases. Kind of embarassing if you send your logging data back to the client as a header... :)
Yes, I agree :-)
I haven't read all the recent patches. Is this problem addressed?
I'd say let the user supply his own logging function which gets all the "Log*" lines TBNL sends to Araneida or standalone-thingy.
*LOG-FUNCTION* or something.
For presentation nobody gets strange header lines. And if you really have to debug you can use a simple function to write in a logfile or use CL-SYSLOG for a more sophisticated way.
This sounds good. I'd just add one thing: this function should be able to return nil or values representing a header's name/value. This would allow the header to be 'handled' or 're-written' or passed-through. I can imagine situations where I'd like to be able to pass log messages back to the client (e.g. debugging a server-server situation)
tbnl-devel site list tbnl-devel@common-lisp.net http://common-lisp.net/mailman/listinfo/tbnl-devel
---- Bob Hutchison -- blogs at http://www.recursive.ca/hutch/ Recursive Design Inc. -- http://www.recursive.ca/
"Bob Hutchison" hutch@recursive.ca wrote:
[...]
The next logical step is to write an HTTP header parser for TBNL (or negotiate with the Araneida folks to use their code).
I would be very interested to add such a front-end to the mod_lisp repository. (Some kind of mod_pure_lisp ;-) Several people (including me) have been interested by the possibility of having a light-weight stand-alone server compatible with mod_lisp (mostly for demonstrations or small apps) without all the overhead and constraints imposed by paserve or areneida. As I posted here some time ago, I used paserve for this but a clean stand-alone HTTP front-end would be nicer.
Marc
On Mar 15, 2005, at 10:24 AM, Marc Battyani wrote:
"Bob Hutchison" hutch@recursive.ca wrote:
[...]
The next logical step is to write an HTTP header parser for TBNL (or negotiate with the Araneida folks to use their code).
I would be very interested to add such a front-end to the mod_lisp repository. (Some kind of mod_pure_lisp ;-) Several people (including me) have been interested by the possibility of having a light-weight stand-alone server compatible with mod_lisp (mostly for demonstrations or small apps) without all the overhead and constraints imposed by paserve or areneida. As I posted here some time ago, I used paserve for this but a clean stand-alone HTTP front-end would be nicer.
I've just written a tiny http header parser that I'll make available real soon. What did you want to do, call mod_lisp directly (e.g. FFI)? or something else?
Cheers, Bob
Marc
---- Bob Hutchison -- blogs at http://www.recursive.ca/hutch/ Recursive Design Inc. -- http://www.recursive.ca/
"Bob Hutchison" hutch@recursive.ca wrote:
On Mar 15, 2005, at 10:24 AM, Marc Battyani wrote:
I would be very interested to add such a front-end to the mod_lisp repository. (Some kind of mod_pure_lisp ;-)
[...]
I've just written a tiny http header parser that I'll make available real soon. What did you want to do, call mod_lisp directly (e.g. FFI)? or something else?
No FFI, just the Lisp HTTP front-end/parser so that it can be used instead of mod_lisp for demos and/or non-critical applications. Just keep mod_lisp compatible headers (the strings in the alist))
Marc
On Mar 15, 2005, at 10:24 AM, Marc Battyani wrote:
"Bob Hutchison" hutch@recursive.ca wrote:
[...]
The next logical step is to write an HTTP header parser for TBNL (or negotiate with the Araneida folks to use their code).
I would be very interested to add such a front-end to the mod_lisp repository. (Some kind of mod_pure_lisp ;-) Several people (including me) have been interested by the possibility of having a light-weight stand-alone server compatible with mod_lisp (mostly for demonstrations or small apps) without all the overhead and constraints imposed by paserve or areneida. As I posted here some time ago, I used paserve for this but a clean stand-alone HTTP front-end would be nicer.
Actually, the bits and pieces that are in TBNL's modlisp.lisp file are probably sufficient to be used as a simple stand-alone server (when the last patch I posted is applied, or Edi releases a new version). I think maybe some small refactoring will make things a bit cleaner, but if you are willing to write a standard TBNL handler for the requests it works now (i.e. you don't have to use any of TBNL's facilities other than the dispatcher, which isn't so bad because you'll probably want to dispatch anyway -- and, if you are using TBNL dispatchers the server is going to be pretty clean as it is).
Cheers, bob
Marc
---- Bob Hutchison -- blogs at http://www.recursive.ca/hutch/ Recursive Design Inc. -- http://www.recursive.ca/
"Bob Hutchison" hutch@recursive.ca wrote:
On Mar 15, 2005, at 10:24 AM, Marc Battyani wrote:
I would be very interested to add such a front-end to the mod_lisp repository. (Some kind of mod_pure_lisp ;-) Several people (including me) have been interested by the possibility of having a light-weight stand-alone server compatible with mod_lisp (mostly for demonstrations or small apps) without all the overhead and constraints imposed by paserve or areneida. As I posted here some time ago, I used paserve for this but a clean stand-alone HTTP front-end would be nicer.
Actually, the bits and pieces that are in TBNL's modlisp.lisp file are probably sufficient to be used as a simple stand-alone server (when the last patch I posted is applied, or Edi releases a new version). I think maybe some small refactoring will make things a bit cleaner, but if you are willing to write a standard TBNL handler for the requests it works now (i.e. you don't have to use any of TBNL's facilities other than the dispatcher, which isn't so bad because you'll probably want to dispatch anyway -- and, if you are using TBNL dispatchers the server is going to be pretty clean as it is).
OK I will look at that in the next release.
Marc
-
Bob Hutchison -
Edi Weitz -
Marc Battyani -
Stefan Scholl