I haven't had a chance to look into it myself but perhaps someone just
knows--since both mod_lisp and Lisplets provide (as I understand it) a
sexp-over-a-socket protocol from a non-Lisp web server to a Lisp
running in a separate process, do they use the *same*
sexp-over-a-socket protocol? If not, is there any technical reason it
would be difficult to unify them?
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
On Fri, 08 Oct 2004 21:28:23 GMT, Peter Seibel <·····@javamonkey.com> wrote:
> I haven't had a chance to look into it myself but perhaps someone
> just knows--since both mod_lisp and Lisplets provide (as I
> understand it) a sexp-over-a-socket protocol from a non-Lisp web
> server to a Lisp running in a separate process, do they use the
> *same* sexp-over-a-socket protocol?
No, they don't. They basically just utilize what the underlying server
(Apache or J2EE) offers, so Lisplets will give you session information
while mod_lisp can't (except for the SSL session).
> If not, is there any technical reason it would be difficult to unify
> them?
I think with enough effort (on the C and Java side - yikes!) it'd be
possible to unify their intersection. But what for?
Cheers,
Edi.
--
Lisp is not dead, it just smells funny.
Real email: (replace (subseq ·········@agharta.de" 5) "edi")
Edi Weitz <········@agharta.de> writes:
> On Fri, 08 Oct 2004 21:28:23 GMT, Peter Seibel <·····@javamonkey.com> wrote:
>
>> I haven't had a chance to look into it myself but perhaps someone
>> just knows--since both mod_lisp and Lisplets provide (as I
>> understand it) a sexp-over-a-socket protocol from a non-Lisp web
>> server to a Lisp running in a separate process, do they use the
>> *same* sexp-over-a-socket protocol?
>
> No, they don't. They basically just utilize what the underlying server
> (Apache or J2EE) offers, so Lisplets will give you session information
> while mod_lisp can't (except for the SSL session).
>
>> If not, is there any technical reason it would be difficult to unify
>> them?
>
> I think with enough effort (on the C and Java side - yikes!) it'd be
> possible to unify their intersection. But what for?
Well, as I under stand it the whole point of mod_lisp (as Marc has
explained just recently) is the easier marketing to folks who are
already running Apache. Presumably Lisplets serve a similar purpose
for folks used to using a Servlet container such as Tomcat or
Weblogic. To the extent they support the same protocol then Lisp code
written for either could run in the other making the Lisp code more
valuable. But if Lisplets provide a richer base (i.e. do more work)
then this might be more trouble than it's worth. (Though if folks were
actually deploying Lisp apps it might make sense to provide a
compatibility API so whatever they do in Lisp when using mod_lisp to
provide the stuff that Lisplets provides (session support, etc) looks
the same to the rest of the code so the same app could run on top of
Apache+mod_lisp+LispSessionsTM or in Lisplets.
-Peter
--
Peter Seibel ·····@javamonkey.com
Lisp is the red pill. -- John Fraser, comp.lang.lisp
Peter Seibel wrote:
> Well, as I under stand it the whole point of mod_lisp (as Marc has
> explained just recently) is the easier marketing to folks who are
> already running Apache. Presumably Lisplets serve a similar purpose
> for folks used to using a Servlet container such as Tomcat or
> Weblogic. To the extent they support the same protocol then Lisp code
> written for either could run in the other making the Lisp code more
> valuable. But if Lisplets provide a richer base (i.e. do more work)
> then this might be more trouble than it's worth. (Though if folks were
> actually deploying Lisp apps it might make sense to provide a
> compatibility API so whatever they do in Lisp when using mod_lisp to
> provide the stuff that Lisplets provides (session support, etc) looks
> the same to the rest of the code so the same app could run on top of
> Apache+mod_lisp+LispSessionsTM or in Lisplets.
>
> -Peter
>
Lisplets are much richer - session management, session state,
application state, user authentication, user roles, portability,
scalability etc. And they are to become richer still, as I am writing a
Lisp interface to JDBC that will be accessible within Lisplet calls.
The one clarification I would like to make is that, while Lisplets
should be immediately useful to Lisp developers already used to using
Tomcat, Weblogic, etc, I think that these servlet containers provide so
much utility that they are worth exploring by anyone who wants to do
Lisp apps with HTTP interfaces.
You can use Lisplets with great success and write no Java or JSP code
whatsoever. So, even for those who have no interest at all in Java,
Lisplets provide a way to leverage huge chunks of multi-platform,
multi-vendor, scalable infrastructure code, so you can stop writing
plumbing (like Lisplets ;-) and get on with writing the intersting parts
of your programs in Lisp.
Rich
"Peter Seibel" <·····@javamonkey.com> wrote
> I haven't had a chance to look into it myself but perhaps someone just
> knows--since both mod_lisp and Lisplets provide (as I understand it) a
> sexp-over-a-socket protocol from a non-Lisp web server to a Lisp
> running in a separate process, do they use the *same*
> sexp-over-a-socket protocol? If not, is there any technical reason it
> would be difficult to unify them?
mod_lisp does not use a sexp over a socket protocol. It's even simpler than
that. The protocol is only key\nvalue\n So that you don't have to call
#'read just #'read-line. It's faster and avoid potential security problems.
Also mod_lisp is quite low level. Lisplets are integrated into Java servlet
containers that provide more services like sessions handling for instance.
With mod_lisp you have to write your own session handling stuff or use TBNL.
So if you want to write a 100% Lisp server, take mod_lisp and if you want
(or need) something that is integrated into a Java servlet containers then
take Lisplets.
Marc
"Marc Battyani" <·············@fractalconcept.com> writes:
> "Peter Seibel" <·····@javamonkey.com> wrote
>
> > I haven't had a chance to look into it myself but perhaps someone just
> > knows--since both mod_lisp and Lisplets provide (as I understand it) a
> > sexp-over-a-socket protocol from a non-Lisp web server to a Lisp
> > running in a separate process, do they use the *same*
> > sexp-over-a-socket protocol? If not, is there any technical reason it
> > would be difficult to unify them?
>
> mod_lisp does not use a sexp over a socket protocol. It's even simpler than
> that. The protocol is only key\nvalue\n So that you don't have to call
Is mod_lisp basically the same as FastCGI then?
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
"jayessay" <······@foo.com> wrote
> "Marc Battyani" <·············@fractalconcept.com> writes:
>
> > "Peter Seibel" <·····@javamonkey.com> wrote
> >
> > > I haven't had a chance to look into it myself but perhaps someone just
> > > knows--since both mod_lisp and Lisplets provide (as I understand it) a
> > > sexp-over-a-socket protocol from a non-Lisp web server to a Lisp
> > > running in a separate process, do they use the *same*
> > > sexp-over-a-socket protocol? If not, is there any technical reason it
> > > would be difficult to unify them?
> >
> > mod_lisp does not use a sexp over a socket protocol. It's even simpler
than
> > that. The protocol is only key\nvalue\n So that you don't have to call
>
> Is mod_lisp basically the same as FastCGI then?
At the beginning it was really like mod_jserv which served me as a model
(but mod_lisp is much faster now). At the functional level,
mod_jserv/FastCGI/mod_cgid/etc. all do the same thing. They transfer the
request decoded by Apache to some outside process. The difference is mostly
that the mod_lisp protocol is much more Lisp friendly (in fact it is much
more friendly for other languages too ;-) and generally much faster as it
keeps an open socket to the Lisp process.
And of course a major difference is that the existence and name of mod_lisp
show that Lisp is not dead and has even its own module to write web
applications with Apache.
Marc
"Marc Battyani" <·············@fractalconcept.com> writes:
> "jayessay" <······@foo.com> wrote
...
> > Is mod_lisp basically the same as FastCGI then?
>
> At the beginning it was really like mod_jserv which served me as a model
> (but mod_lisp is much faster now). At the functional level,
> mod_jserv/FastCGI/mod_cgid/etc. all do the same thing. They transfer the
> request decoded by Apache to some outside process. The difference is mostly
> that the mod_lisp protocol is much more Lisp friendly (in fact it is much
> more friendly for other languages too ;-)
Presumably you mean friendlier at the socket protocol level, since it
sounds like the basic information structure for all of them is a set
of nv-pairs. I'm only familiar (at this level) with FastCGI, for
which this is indeed true and your previous comment seems to indicate
this is true of mod_lisp as well.
If this is true, then once you have a fastcgi.cl or a mod-list.cl
"module" for the lisp side, there shouldn't be much (any?) difference
between them. If this is incorrect, could you say a little more about
this issue? Thanks.
> and generally much faster as it keeps an open socket to the Lisp
> process.
But that is what FastCGI does as well (and that is also what mod_jserv
does for a java server/servlet). That's the whole point of the "fast"
in the name.
> And of course a major difference is that the existence and name of
> mod_lisp show that Lisp is not dead and has even its own module to
> write web applications with Apache.
Right, that is a good thing. OTOH, the FastCGI route gives another
level of "political" acceptance.
We also have a java servlet mediating between browser applet clients
and a lisp server. This uses jserv (would need to move to something
even worse such as tomcat for apache 2 or other servers) which has the
"political" advantage of being completely familiar to customers with
the typical garbage installed. But technically is sucks and moving to
tomcat sucks even more. I was thinking of replacing the whole thing
with a lisp mediator and thought mod_lisp could be of use here, as I
thought it provided a more general protocol than something like
fastcgi. I guess I will need to take a closer look at mod_list and/or
rethink the thing.
/Jon
--
'j' - a n t h o n y at romeo/charley/november com
Peter Seibel wrote:
> I haven't had a chance to look into it myself but perhaps someone just
> knows--since both mod_lisp and Lisplets provide (as I understand it) a
> sexp-over-a-socket protocol from a non-Lisp web server to a Lisp
> running in a separate process, do they use the *same*
> sexp-over-a-socket protocol? If not, is there any technical reason it
> would be difficult to unify them?
>
> -Peter
>
I don't think mod_lisp uses sexprs, but if it were to, it shouldn't be a
problem to use a subset of the Lisplets protocol (which is still subject
to change if I get any feedback):
(excerpted from http://lisplets.sourceforge.net/#request )
-----------------
All information about the request is sent in a single list. All members
of that list are themselves lists, each beginning with a tag. The
top-level entries are:
* (method a-string)
* (uri a-string)
* (protocol a-string)
* (is-secure a-boolean)
* (headers
o (name value ...) ...)
* (cookies
o (name value) ...)
* (params
o (name value ...) ...)
* (context
o (name a-string)
o (params (name value) ...)
o (attrs (name value) ...))
* (servlet
o (name a-string)
o (params (name value) ...))
* (session
o (id a-string)
o (is-new a-boolean)
o (creation-time an-int)
o (last-accessed-time an-int)
o (max-inactive-interval an-int)
o (attrs (name value) ...))
* (user
o (name a-string)
o (auth-type a-string)
o (roles (name a-boolean) ...))
The entries are not guaranteed to come in any particular order, nor are
they all guaranteed to be present.
(Similar idea coming back - see
http://lisplets.sourceforge.net/#response )
--------------------
So, mod-lisp or any other non-servlet-based HTTP API could omit the
context, servlet, session and user sections and still be conformant. Of
course, those sections are a big part of the value-add of servlet
containers.
Rich
"Rich Hickey" <···········@SPPAMMrichhickey.com> wrote
> So, mod-lisp or any other non-servlet-based HTTP API could omit the
> context, servlet, session and user sections and still be conformant. Of
> course, those sections are a big part of the value-add of servlet
> containers.
Changing the mod_lisp or lisplets protocols to be compatible is useless IMO
for the following reasons:
It's so easy to deal with both protocols at the Lisp side that it's not
useful do make the change at the C/Java side where it's much more painful.
If you use the session/user management of the servlet container then you can
only use lisplets so mod_lisp compatibility is useless.
If you don't need this then you probably don't want to have the servlet
container overhead and should take mod_lisp. And if you want to switch to
lisplets anyway because you must work in a Java environment then it's not a
problem anyway (see the first point).
Marc