We are happy to announce the public availability of a toolkit for
writing web-enabled Common Lisp applications.
The toolkit is called 'IMHO' (Note 1), and it is available at:
http://alpha.onshore.com/lisp-software/
Method of operation:
Applications written using this system exist inside of a long-running
lisp process, which services connections from Apache via a socket from
the Java Apache project's JServ module.
Applications consist of sets of CLOS objects representing HTML
elements and interface components, statefulness is explicitly managed,
form processing is simple and getting simpler, and there is some
degree of support for integration with JavaScript, and communications
with browser-side components via serialized Java objects.
This system is particularly nice in conjunction with an RDBMS backend,
in our case provided by Pierre Mai's 'MaiSQL'. We have written
extensions to his package which provide square-bracket SQL reader
syntax, 'view class' object-relational mapping, and the rudiments of
an Oracle OCI interface, gleaned from Winton Davies' and William
Newman's work, as published by Cadabra Inc.--these are also available
at the same location.
Other notes:
The sources at present are oriented towards CMUCL systems, loaded via
mk-defsystem, but it should be no great shakes to get much of it
working under anything else that has a CLOS, a MOP, and a minimal
socket interface.
Source to all components is distributed under X consortium style
licenses, or existing free licenses where applicable, so share and
enjoy.
This is still a bit of a work in progress, of which we have
implemented chunks as needed, while trying to keep the overall
outlines clear. We're highly interested in seeing it become a really
great system for delivering complex applications: feedback, criticism,
encouragement, and so forth are all very much welcomed.
Jesse Bouwman and Craig Brozefsky
onShore, Inc.
1. 'Internet-Meta-humble-Objects': we were ay one point fairly devoted
to NeXT's WebObjects, which supplies part of the etymological
derivation.
·····@onshore.com wrote:
>
> [announcement of new lisp web system]
>
Sounds interesting.
>
> Applications consist of sets of CLOS objects representing HTML
> elements and interface components, statefulness is explicitly managed,
> form processing is simple and getting simpler, and there is some
> degree of support for integration with JavaScript, and communications
> with browser-side components via serialized Java objects.
>
To what extent does the above paragraph dictate how applications must
be written to work with the web server interface component? We have a
language for doing web apps:
http://www.genworks.com/portfolio/papers/gwl/gwl-html/index.html
(soon to be hosted at sourceforge)
which currently works via cl-http. Would there be merit in looking at
using your system as an alternative to cl-http, but without necessarily
using all of your system's application-building components (basically,
just using the web server interface layer plus whatever else is
necessary to talk to it at a basic level), and possibly migrating
into using more of your system's application-building components
gradually as appropriate?
Not that we have any immediate plans to drop cl-http either, mind you.
Yours,
-dave
--
David J. Cooper Jr, Chief Engineer Genworks International
·······@genworks.com 5777 West Maple, Suite 130
(248) 932-2512 (Genworks HQ/voicemail) West Bloomfield, MI 48322-2268
(248) 407-0633 (pager) http://www.genworks.com
I would like to merge two threads:
1) ANN: CL application server, mit source
2) CL-HTTP performance (was 'Common Lisp interpretation by emacs')
First off lets get one thing straight, I am just as much of a dumbass as the
next person, so if I am totally off the deep end please insert your wisdom.
I really want to see some verbosity on this topic, because it ought be hot
one for lisp.
WWW-CL
lately some very good points on this issue:
Will Hartung said:
>IMHO, the time on Lisp shouldn't be spent on making an efficient HTTP
>server. There are a LOT of efficient HTTP servers. Rather, the time should
>be spent on making an efficient Lisp Application Server that interfaces
with
>the Big 3 HTTP servers. In one sense, much of the base infrastructure is
>similiar, having a server that responds to multiple requests over a socket,
>and all the pain of threading and state management, etc, that it entails.
The detail is the protocol, and the stability of the client.
>...
>Why keep up with the joneses? Why constantly re-invent the wheel? The
>fastest web servers today are lousy application servers. One mistake and
the
>whole server explodes. But they're great at sucking data out of file
systems
>and sockets, and spitting them out as HTTP messages.
>Focus on the creation and management of content to user, and let the web
>mechanics worry about delivering it.
please take a look at that thread.
Fernando:
>Amen. :-) Do you know if there's someone working on this? O:-)
·····@onshore.com:
>ANN: CL application server, mit source
(I will be taking a look at this system for sure)
please take a look at that thread.
please take a look at this web site too:
http://www.alibre.com/
These are some dallas-based java hackers that have shown me their system.
It is mechanical-cad, (which is something I like to do) therefore, I am
pointing it out.
It just as well could be a spreadsheet or an expert system.
The point I would like to make is, despite the fact it is Java, it is
probably the most completely bad-ass web application I have seen.
They tell me everything is in java, I am somewhat skeptical of that, but
thats what I was told.
It is a complete mechanical cad system (very group-oriented) that runs
inside internet exploder.
I have also seen lots of other things run in explorer or netscape as java
such as microsoft terminal server edition client.
As internet connections get faster we are going to see more and more of this
stuff, and it is what Joe is going to call the World Wide Web.
At some point the Java hackers are going to get the bugs worked out of the
JVM(s).
We will no longer be worrying about the 99 different ways to print HTML with
CL.
(and which socket to use)
We will be worrying about how to interface with the plethora of Java UI
toolkits that will come.
Lisp is always going to make a decent server, I am not worried about that.
What I am concerned with is what Joe and friends see when they turn on their
first imac.
They are going to see Java.
If we care for them to see Lisp we need our own native UI toolkit. (do we
care?)
It should at least do #1 and maybe some of the rest of these items:
1.) Interface with the browser using Common Lisp source compiled direct to
Java byte code.
(do things like be able to inherit from the java applet object and access
the document object directly)
2.) Interface with the browser using XML (is this going to be the
replacement for HTML?)
3.) Be the natural evolution of CLIM and everything that we have learned
from widget toolkits.
(because Sun has declared the internet is the machine, and my last lisp
machine ran CLIM)
Unless of course someone has enough pull with Bill Gates to make the VLM the
hottest new addition to explorer hopefully spawning Mozilla to do the same.
Personally, I am loving CL and my recent discovery of the MOP.
(feels sort of like discovering Lisp all over again)
Unfortunately, I am beginning to feel naked without knowing Java (and
calling myself a web developer)
At this point my friends who hack perl, HTML, flash, lotus notes domino, and
javascript get by just fine. They don't really know what the hell I am
talking about when I say dynamic.
Dynamic to them means changing the source code.
They find it much more impressive that I run linux than that I run lisp.
So lets get the goods together and get it under a license that will best
serve the Lisp community.
Are presentation types and widgets incompatible?
(I would like to see a new ui paradigm that makes the most of both of these
ideas)
Or is this something that can only be accomplished as a private commercial
endeavor?
WWW interfacing seems to be less of a feature of an application and more of
a requirement.
To those who have implemented a GUI in lisp:
Am I off the deep-end?
I am willing to learn Java in order to contribute to such a project.
If you need a binary file upload for CL-HTTP, I have one.
Andrew K. Wolven
Andrew K. Wolven <·······@redfernlane.org> wrote in message
······················@redfernlane.org...
.../...
> To those who have implemented a GUI in lisp:
> Am I off the deep-end?
Yes. Java is not a good choice anymore to do remote UI.
The hot trend is to do them in DHTML/JavaScript.
> I am willing to learn Java in order to contribute to such a project.
Learn JavaScript + DHTML instead. IMHO.
Marc Battyani
Marc Battyani wrote:
> Andrew K. Wolven <·······@redfernlane.org> wrote in message
> ······················@redfernlane.org...
>
> .../...
>
> > To those who have implemented a GUI in lisp:
> > Am I off the deep-end?
>
> Yes. Java is not a good choice anymore to do remote UI.
> The hot trend is to do them in DHTML/JavaScript.
>
> > I am willing to learn Java in order to contribute to such a project.
>
> Learn JavaScript + DHTML instead. IMHO.
>
> Marc Battyani
I will be asking my web hacker friend at the coffee shop about DHTML,
but Javascript?
Would that be Netscape Navigator Javascript or Internet Explorer
Javascript?
So far simple-simple things do not seem to be cross compatible.
(like on-mouse-over changing colors of links)
Perhaps I am not using ANSI Javascript.
AKW
Andrew K. Wolven <·······@redfernlane.org> wrote in message
······················@redfernlane.org...
> Would that be Netscape Navigator Javascript or Internet Explorer
> Javascript?
ECMA Script is the norm + extentions from NS + M$
> So far simple-simple things do not seem to be cross compatible.
> (like on-mouse-over changing colors of links)
Yes, it's why it makes sense to generate this stuff from Lisp
Marc Battyani
"Marc Battyani" <·············@csi.com> writes:
> Yes. Java is not a good choice anymore to do remote UI.
> The hot trend is to do them in DHTML/JavaScript.
Hrmf. javascript is probably the most stupid invention since september
started lasting forever. Anybody with the slightest concern for privacy
and security has to turn it off in his browser anyway...
--
(espen)
Espen Vestre <·····@*do-not-spam-me*.vestre.net> wrote in message
···················@wallace.nextel.no...
> "Marc Battyani" <·············@csi.com> writes:
>
> > Yes. Java is not a good choice anymore to do remote UI.
> > The hot trend is to do them in DHTML/JavaScript.
>
> Hrmf. javascript is probably the most stupid invention since september
> started lasting forever. Anybody with the slightest concern for privacy
> and security has to turn it off in his browser anyway...
I you don't like JavaScript, you can use other languages as scripting
engine.
So far you can use Python, Haskell, PERL or VB. (maybe more ?)
I once played with the idea of turning Common Lisp in a Scripting Engine,
but now I think that Common Lisp is best suited for server tasks. This idea
could be worthwhile with a smaller lisp like ISO lisp.
Marc Battyani
In article <··················································@lp.airnews.net>,
Marc Battyani <·············@csi.com> wrote:
>
>Espen Vestre <·····@*do-not-spam-me*.vestre.net> wrote in message
>···················@wallace.nextel.no...
>> Hrmf. javascript is probably the most stupid invention since september
>> started lasting forever. Anybody with the slightest concern for privacy
>> and security has to turn it off in his browser anyway...
>
>I you don't like JavaScript, you can use other languages as scripting
>engine.
>So far you can use Python, Haskell, PERL or VB. (maybe more ?)
Client-side scripting a la JavaScript, in general, is relatively hard
to make secure. Python, Haskell, Perl, and Basic all have the same
problem as JavaScript when run client-side in what is intended to be a
secure environment.
Client-side scripting a la JavaScript is probably not impossible to
make secure. But securing it and verifying its security is a very
complex endeavor, and complexity is the greatest enemy of security. I
think that, while it is not impossible, it is not practically
possible.
Client-side scripting in a compartment secured by simpler means --- a
KeyKOS domain, for example --- might be practically possible to secure.
--
<······@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08. Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.html>
The power didn't go out on 2000-01-01 either. :)
* Kragen Sitaker wrote:
> Client-side scripting a la JavaScript is probably not impossible to
> make secure. But securing it and verifying its security is a very
> complex endeavor, and complexity is the greatest enemy of security. I
> think that, while it is not impossible, it is not practically
> possible.
If course, ensuring security is a whole bunch easier if you have a
source form which you check easily. For instance, you can tweak READ
not to do anything bad (turn off read-time eval), then you can walk
the resulting form to check it does not do anything bad (make sure it
only uses a known good set of symbols), and then as far as I can see
you are at the mercy of DoS attacks due to nontermination or excessive
memory use, and also perhaps of the error system not catching
something and letting the program blunder on regardless, which is
really an implementation issue (most of them seem to catch most stuff
as far as I can see, anyway you can check with the vendor).
Perhaps I've missed something here, and of course the `known good set'
is a way of getting round all the nasty problems, but it doesn't look
too bad to me for Lisp.
--tim
In article <···············@cley.com>, Tim Bradshaw <···@cley.com> wrote:
>* Kragen Sitaker wrote:
>> Client-side scripting a la JavaScript is probably not impossible to
>> make secure. But securing it and verifying its security is a very
>> complex endeavor, and complexity is the greatest enemy of security. I
>> think that, while it is not impossible, it is not practically
>> possible.
>
>Perhaps I've missed something here, and of course the `known good set'
>is a way of getting round all the nasty problems, but it doesn't look
>too bad to me for Lisp.
It's no worse for Lisp than for anything else. But it's also no better.
>If course, ensuring security is a whole bunch easier if you have a
>source form which you check easily. For instance, you can tweak READ
>not to do anything bad (turn off read-time eval), then you can walk
>the resulting form to check it does not do anything bad (make sure it
>only uses a known good set of symbols),
In order to successfully interpret the program, your interpreter needs
to understand it at this level already.
An equivalent method that is more likely to be correct is to evaluate
the program in a limited environment, in which only that known good set
of symbols is meaningful. This has been done with JavaScript, Tcl, and
Perl, and probably the other languages mentioned as well.
The trouble is: what do you put in that known-good set of symbols? The
bigger it is, the more possible security holes you have. The smaller
it is, the less likely anyone will want to use it.
And implementors frequently seem to succumb to the temptation to make
their interpreter capable of handling scripts at several different
security levels, including a "completely trusted" level, so they don't
have to write the whole browser in C. This is frequently slightly botched.
> and then as far as I can see
>you are at the mercy of DoS attacks due to nontermination or excessive
>memory use,
These are relatively easy to handle in an interpreter, if you don't
mind approximating "nontermination" with "failure to terminate within a
given time". MOO does it, for example. Handling them in a compiler is
possible, but code intended to have its hands tied by type-safety is
even more likely to be able to escape if compiled than if interpreted.
> and also perhaps of the error system not catching
>something and letting the program blunder on regardless, which is
>really an implementation issue (most of them seem to catch most stuff
>as far as I can see, anyway you can check with the vendor).
I don't remember whether JavaScript holes have been attributed to this
cause, but I suspect they have.
--
<······@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08. Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.html>
The power didn't go out on 2000-01-01 either. :)
Marc Battyani wrote:
> Espen Vestre <·····@*do-not-spam-me*.vestre.net> wrote in message
> ···················@wallace.nextel.no...
> > "Marc Battyani" <·············@csi.com> writes:
> >
> > > Yes. Java is not a good choice anymore to do remote UI.
> > > The hot trend is to do them in DHTML/JavaScript.
> >
> > Hrmf. javascript is probably the most stupid invention since september
> > started lasting forever. Anybody with the slightest concern for privacy
> > and security has to turn it off in his browser anyway...
>
> I you don't like JavaScript, you can use other languages as scripting
> engine.
>
The only 'scripting' I have done is with Nichimen Dynamics (a CL scripting
engine!). The language I used involved pointing and clicking (ok, so maybe I
typed a number or two). Thats really about the only kind of scripting I
envision myself doing.
* Marc Battyani wrote:
> I you don't like JavaScript, you can use other languages as scripting
> engine.
> So far you can use Python, Haskell, PERL or VB. (maybe more ?)
Which of these have any serious security features (Java or better)?
(It's reasonably easy to provide secure CL if you are willing to have
source code in the web page.)
--tim
Tim Bradshaw <···@cley.com> wrote in message
····················@cley.com...
> * Marc Battyani wrote:
>
> > I you don't like JavaScript, you can use other languages as scripting
> > engine.
> > So far you can use Python, Haskell, PERL or VB. (maybe more ?)
>
> Which of these have any serious security features (Java or better)?
> (It's reasonably easy to provide secure CL if you are willing to have
> source code in the web page.)
I was refering to the language choice you had in a brower today not to what
they let you do in it.
The security is not a language related issue. It's rather related to the
library of function that you have in each environment and the executing
model.
Marc Battyani
* Marc Battyani wrote:
> I was refering to the language choice you had in a brower today not to what
> they let you do in it.
> The security is not a language related issue. It's rather related to the
> library of function that you have in each environment and the executing
> model.
It's not a language-related issue in the same sense that all languages
are the same because they're all turing-equivalent. If I give you a
large chunk of random VB and a large chunk of random ML I know which
one *I'd* rather attempt to prove safe.
--tim
Tim Bradshaw <···@cley.com> wrote in message
····················@cley.com...
...
> If I give you a
> large chunk of random VB and a large chunk of random ML I know which
> one *I'd* rather attempt to prove safe.
Please don't!
My previous posts where just tolding you that you could stop to use VB in
the browsers and use Haskell instead...
Marc Battyani
In article <·················@redfernlane.org>,
Andrew K. Wolven <·······@redfernlane.org> wrote:
>Just what exactly are the security issues with embedded browser languages?
>
>(back to java)
>I thought with the restrictions on the JVM and what an applet is allowed to
>do, this has taken care of security issues. (I don't know)
The JVM is theoretically almost perfect, as far as I know. I think one
or two minor security bugs were found in the spec early on, but they
were fixed.
Theory and practice are a long way apart. Implementing the JVM spec
--- itself a book-length text, and in fact a book --- is a complex
task.
That goes double for JavaScript.
--
<······@pobox.com> Kragen Sitaker <http://www.pobox.com/~kragen/>
The Internet stock bubble didn't burst on 1999-11-08. Hurrah!
<URL:http://www.pobox.com/~kragen/bubble.html>
The power didn't go out on 2000-01-01 either. :)
Espen Vestre wrote:
> Hrmf. javascript is probably the most stupid invention since september
> started lasting forever. Anybody with the slightest concern for privacy
> and security has to turn it off in his browser anyway...
The functionality of Javascript is pretty limited - for example, the
most it can do with your hard drive is saving and sending cookies. Do
you perhaps think of VB or ActiveX? Also, Javascript is a minimal
prototype-based Lisp in its heart.
Robert
Robert Monfera <·······@fisec.com> writes:
> The functionality of Javascript is pretty limited - for example, the
> most it can do with your hard drive is saving and sending cookies. Do
maybe in theory. In practice, the two leading implementations are so
rotten that - at best! - everyone can read anything they like off your
hard drive (for instance, this is almost trivially simple with Netscape
versions up to 4.05 and 4.5). (ironically, the commercialized maintainers
of the bugtraq archives, http://www.securityfocus.com, require javascript
enabled to let you search the archives for "javascript" and find out that
you need to turn it off :-( )
--
(espen)
In article <·················@fisec.com>,
Robert Monfera <·······@fisec.com> wrote:
> Also, Javascript is a minimal
> prototype-based Lisp in its heart.
I hope not: much of Lisp is about doing a good
job at scoping, and JavaScript scoping is completely
broken.
Sent via Deja.com http://www.deja.com/
Before you buy.
"Andrew K. Wolven" <·······@redfernlane.org> writes:
> please take a look at this web site too:
>
> http://www.alibre.com/
>
> These are some dallas-based java hackers that have shown me their
> system. It is mechanical-cad, (which is something I like to do)
> therefore, I am pointing it out. It just as well could be a
> spreadsheet or an expert system.
>
> The point I would like to make is, despite the fact it is Java, it is
> probably the most completely bad-ass web application I have seen.
> They tell me everything is in java, I am somewhat skeptical of that, but
> thats what I was told.
https://www.alibre.com/myprojects/default.asp yields:
This Netscape browser is not currently supported for use with the
Alibre Design Service. Please download the latest version of
Microsoft's Internet Explorer.
Return to www.alibre.com
If it's really in Java, why does it require Internet Explorer?
--
Harvey Stein
Bloomberg LP
·······@bfr.co.il
"David J. Cooper" <·······@genworks.com> writes:
> ·····@onshore.com wrote:
> >
> > Applications consist of sets of CLOS objects representing HTML
> > elements and interface components, statefulness is explicitly managed,
> > form processing is simple and getting simpler, and there is some
> > degree of support for integration with JavaScript, and communications
> > with browser-side components via serialized Java objects.
>
> To what extent does the above paragraph dictate how applications must
> be written to work with the web server interface component?
I'll try to clarify a little bit. We began working in CL-HTTP about 9
months ago, and realized that we were writing a lot of computed URL
exports, like the following:
(export-url #u"/foo.html"
:computed
:response-function #'write-foo
:public t
...)
rather than one or two 'complex' exports, viz. the mail-archive
example that comes with CL-HTTP, since many of the form-inputs, data
browsers and other pieces of code each seemed to require a distinct
response-function (and it's nice to have distinct URLs).
Moreover, it's really helpful in the context of this kind of
development to try to make a clean seperation between static elements
of the pages, and dynamically generated ones, so that graphic
designers can work in parallel with programmers--and cl-http doesn't
seem to support, for instance, page templates in an obvious way. If
anyone here has done any work with WebObjects, you may be familiar
with how this works, by taking HTML templates, and expanding tags that
refer to application objects.
It's nice to be able to serve up images, etc. through cl-http, but
Apache et al. do such a good job with this kind of thing that it seems
a little silly to spend a lot of time on it.
So CL-HTTP sort of lost its attraction for us.
I think what we have replaced it with has a lot of flexibility. It
looks like its model is pretty similar to GWL's model, but using basic
CLOS machinery, rather than presentation types.
Here's a simple example:
(defapplication simple
:main-class test
:base-url "simple"
:doc-root "/simple/"
:template-root "simple:templates;")
This establishes the 'url area' for the application (I think Java
servlets do something similar).
(defclass test (html-element)
)
This provides the default 'page'. There is a generic function called
'render-html' specialized on {html-element, stream}, which provides
default display behavior by mapping the element class-name to an html
template; in this case, it would be #p"simple:templates;test.html"
A request to http://localhost/app/simple/test would simply return the
contents of this template, then, or you can specialize render-html and
do the drawing yourself.
> We have a
> language for doing web apps:
>
> http://www.genworks.com/portfolio/papers/gwl/gwl-html/index.html
>
> (soon to be hosted at sourceforge)
>
> which currently works via cl-http. Would there be merit in looking at
> using your system as an alternative to cl-http, but without necessarily
> using all of your system's application-building components (basically,
> just using the web server interface layer plus whatever else is
> necessary to talk to it at a basic level), and possibly migrating
> into using more of your system's application-building components
> gradually as appropriate?
This is really similar in a lot of ways: we also provide generation of
hrefs between elements ('page' components, in GWL's lingo?), and trees
of child elements (:children). In our system, we generally add
children to the element objects in shared-initialize (we ought to wrap
that up a bit better), and draw them with recursive calls to
render-html, or by tag expansion from templates:
(defclass test (html-element)
)
(defmethod shared-initialize ((test test) slots &rest)
(call-next-method)
(instantiate-children
test
`(("prompt" static-string
:value "Some prompting text"))))
in combination with:
(defmethod render-html ((test test) stream)
(with-tag (:tag "H1" :stream stream)
(render-html (child-element test "prompt") stream)))
Same results should be had by not specializing render-html, and
instead putting this in #p"simple:templates;test.html":
<H1><IMHO name="prompt"></H1>
I hope that provides some idea of the scope of what we want to do.
Regards,
Jesse Bouwman
<·····@onshore.com>
·····@onshore.com wrote:
> "David J. Cooper" <·······@genworks.com> writes:
>
> > ·····@onshore.com wrote:
> > >
> > > Applications consist of sets of CLOS objects representing HTML
> > > elements and interface components, statefulness is explicitly managed,
> > > form processing is simple and getting simpler, and there is some
> > > degree of support for integration with JavaScript, and communications
> > > with browser-side components via serialized Java objects.
> >
> > To what extent does the above paragraph dictate how applications must
> > be written to work with the web server interface component?
>
> I'll try to clarify a little bit. We began working in CL-HTTP about 9
> months ago, and realized that we were writing a lot of computed URL
> exports, like the following:
>
> (export-url #u"/foo.html"
> :computed
> :response-function #'write-foo
> :public t
> ...)
>
> rather than one or two 'complex' exports, viz. the mail-archive
> example that comes with CL-HTTP,
Exactly. My current problem with CL-HTTP (or ACL?) is that I want to parse
the url myself an map it straight to our own object heirarchy. I have to go
around CL-HTTP's built in mechanism to do this.
> since many of the form-inputs, data
> browsers and other pieces of code each seemed to require a distinct
> response-function (and it's nice to have distinct URLs).
>
> Moreover, it's really helpful in the context of this kind of
> development to try to make a clean seperation between static elements
> of the pages, and dynamically generated ones, so that graphic
> designers can work in parallel with programmers--and cl-http doesn't
> seem to support, for instance, page templates in an obvious way. If
> anyone here has done any work with WebObjects, you may be familiar
> with how this works, by taking HTML templates, and expanding tags that
> refer to application objects.
>
I was planning on adding shtml widgets to my list.
I have friends that don't do lisp.
>
> It's nice to be able to serve up images, etc. through cl-http, but
> Apache et al. do such a good job with this kind of thing that it seems
> a little silly to spend a lot of time on it.
>
heck, why not go one step further and put your images on a high speed hosting
site.
CL-HTTP does just fine w/ images anyhoo.
>
> So CL-HTTP sort of lost its attraction for us.
>
was it the technology or the vague commercial license?
>
> I think what we have replaced it with has a lot of flexibility. It
> looks like its model is pretty similar to GWL's model, but using basic
> CLOS machinery, rather than presentation types.
>
> Here's a simple example:
>
> (defapplication simple
> :main-class test
> :base-url "simple"
> :doc-root "/simple/"
> :template-root "simple:templates;")
>
> This establishes the 'url area' for the application (I think Java
> servlets do something similar).
>
> (defclass test (html-element)
> )
>
> This provides the default 'page'. There is a generic function called
> 'render-html' specialized on {html-element, stream}, which provides
> default display behavior by mapping the element class-name to an html
> template; in this case, it would be #p"simple:templates;test.html"
>
> A request to http://localhost/app/simple/test would simply return the
> contents of this template, then, or you can specialize render-html and
> do the drawing yourself.
>
> > We have a
> > language for doing web apps:
> >
> > http://www.genworks.com/portfolio/papers/gwl/gwl-html/index.html
> >
> > (soon to be hosted at sourceforge)
> >
> > which currently works via cl-http. Would there be merit in looking at
> > using your system as an alternative to cl-http, but without necessarily
> > using all of your system's application-building components (basically,
> > just using the web server interface layer plus whatever else is
> > necessary to talk to it at a basic level), and possibly migrating
> > into using more of your system's application-building components
> > gradually as appropriate?
>
> This is really similar in a lot of ways: we also provide generation of
> hrefs between elements ('page' components, in GWL's lingo?), and trees
> of child elements (:children). In our system, we generally add
> children to the element objects in shared-initialize (we ought to wrap
> that up a bit better), and draw them with recursive calls to
> render-html, or by tag expansion from templates:
>
> (defclass test (html-element)
> )
>
> (defmethod shared-initialize ((test test) slots &rest)
> (call-next-method)
> (instantiate-children
> test
> `(("prompt" static-string
> :value "Some prompting text"))))
>
> in combination with:
>
> (defmethod render-html ((test test) stream)
> (with-tag (:tag "H1" :stream stream)
> (render-html (child-element test "prompt") stream)))
>
> Same results should be had by not specializing render-html, and
> instead putting this in #p"simple:templates;test.html":
>
> <H1><IMHO name="prompt"></H1>
>
> I hope that provides some idea of the scope of what we want to do.
>
> Regards,
>
> Jesse Bouwman
> <·····@onshore.com>
From your more detailed description I can see that you are basically doing the
same thing as Genworks<sup><small>®</small></sup>.
AKW
"Andrew K. Wolven" <·······@redfernlane.org> writes:
> > rather than one or two 'complex' exports, viz. the mail-archive
> > example that comes with CL-HTTP,
>
> Exactly. My current problem with CL-HTTP (or ACL?) is that I want to parse
> the url myself an map it straight to our own object heirarchy. I have to go
> around CL-HTTP's built in mechanism to do this.
This is possible with cl-http. In fact, the first "shim" we used for
IMHO was cl-http itself. You will need a relatively recent version of
cl-http and need to enable URL-AREAS. For a more detailed discussion
of this issue, see the thread on the topic in the www-cl archives:
http://wilson.ai.mit.edu/cl-http/archives/www-cl?Thread-192
I eventually produced a patch for this which I'm unable to locate at
this time, sorry.
> > So CL-HTTP sort of lost its attraction for us.
> >
> was it the technology or the vague commercial license?
For me it was a combination of both, plus the technical merits of
using the webserver shim.
> From your more detailed description I can see that you are basically
> doing the same thing as Genworks<sup><small>®</small></sup>.
I think there is sufficient difference between the two systems that
they can stand on their own. Once one starts working with either of
them, they'll be a bit more distinct. I would like to have support
for both mechanisms.
--
Craig Brozefsky <·····@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig
"Hiding like thieves in the night from life, illusions of
oasis making you look twice. -- Mos Def and Talib Kweli
Craig Brozefsky <·····@red-bean.com> writes:
> This is possible with cl-http. In fact, the first "shim" we used for
Pardon my ignorance, but what is a "shim"?
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
From: William Deakin
Subject: Re: ANN: CL application server, mit source
Date:
Message-ID: <38E31135.2308C880@pindar.com>
Marco Antoniotti wrote:
> ...what is a "shim"?
AFAIK, it is a term borrowed from engineering or fixing things like
motorbikes. It is like a thin (often soft) washer that allows a nut to be
tightened more by compressing the soft metal shim or as a thin spacer used
to pad out the thread of a bolt. (For example: I know (motor)biker people
who make shims out of softdrinks cans. I've made shims for push bikes in a
similar fashion.)
As for a literary reference (IIRC) shims come up in `Zen and the Art of
Motorcycle Maintainance' by Robert Pirsig (a good book [1]).
Cheers,
:) will
[1] if you put any store in my recommendations anymore ;)
William Deakin <·····@pindar.com> writes:
> Marco Antoniotti wrote:
>
> > ...what is a "shim"?
>
> AFAIK, it is a term borrowed from engineering or fixing things like
> motorbikes. It is like a thin (often soft) washer that allows a nut to be
> tightened more by compressing the soft metal shim or as a thin spacer used
> to pad out the thread of a bolt. (For example: I know (motor)biker people
> who make shims out of softdrinks cans. I've made shims for push bikes in a
> similar fashion.)
Thanks.
> As for a literary reference (IIRC) shims come up in `Zen and the Art of
> Motorcycle Maintainance' by Robert Pirsig (a good book [1]).
Yeah! I should have remembered about teh friend with the brand new
BWM! :)
Cheers
--
Marco Antoniotti ===========================================
PARADES, Via San Pantaleo 66, I-00186 Rome, ITALY
tel. +39 - 06 68 10 03 17, fax. +39 - 06 68 80 79 26
http://www.parades.rm.cnr.it/~marcoxa
William Deakin <········@pindar.com> wrote:
+---------------
| Marco Antoniotti wrote:
| > ...what is a "shim"?
|
| AFAIK, it is a term borrowed from engineering or fixing things like
| motorbikes. It is like a thin (often soft) washer that allows a nut to be
| tightened more by compressing the soft metal shim or as a thin spacer...
+---------------
And in the context of protocol stacks, a shim is a thin layer that adapts
(or "harmonizes", as they say in standards-speak) the layers above & below
it to each other. Also known as "glue code".
-Rob
-----
Rob Warnock, 41L-955 ····@sgi.com
Applied Networking http://reality.sgi.com/rpw3/
Silicon Graphics, Inc. Phone: 650-933-1673
1600 Amphitheatre Pkwy. PP-ASEL-IA
Mountain View, CA 94043
"Andrew K. Wolven" wrote:
>
> From your more detailed description I can see that you are basically doing the
> same thing as Genworks<sup><small>®</small></sup>.
>
> AKW
They are doing similar to what we will be doing when we start
having "writers" and "companions" in gdl (drl) and gwl. They still
don't have demand-driven evaluation with automatic caching and
dependency-tracked "bashing" though.
-dave
--
David J. Cooper Jr, Chief Engineer Genworks International
·······@genworks.com 5777 West Maple, Suite 130
(248) 932-2512 (Genworks HQ/voicemail) West Bloomfield, MI 48322-2268
(248) 407-0633 (pager) http://www.genworks.com
"David J. Cooper" <·······@genworks.com> writes:
> > Applications consist of sets of CLOS objects representing HTML
> > elements and interface components, statefulness is explicitly managed,
> > form processing is simple and getting simpler, and there is some
> > degree of support for integration with JavaScript, and communications
> > with browser-side components via serialized Java objects.
> >
>
> To what extent does the above paragraph dictate how applications must
> be written to work with the web server interface component? We have a
> language for doing web apps:
I don't understand the question really, since I don't see how the
above paragraph can dictate anything, but I'll assume that you are
asking how much does the basic webserver shim assume about the
application on the backend. The answer is, not much. The shim talks
to the rest of the system thru an application object, which implements
a handle-request method which takes the application object in
question, and a request object. The application is then responsible
for generating all output and deciding what to do with the url and any
including form information. The application uses the response stream
supplied in the request object to write it's output to the user.
> which currently works via cl-http. Would there be merit in looking
> at using your system as an alternative to cl-http, but without
> necessarily using all of your system's application-building
> components (basically, just using the web server interface layer
> plus whatever else is necessary to talk to it at a basic level), and
> possibly migrating into using more of your system's
> application-building components gradually as appropriate?
Our html generating macros are underdeveloped (but there) in
comparisons to cl-http since we primarily use templates, and our form
processing is not based on cl-http presentation types, which we do not
really support, so moving your system over would require migrating
alot of cl-http code perhaps, or reproducing it. But as far as just
talking to it, define a new application class and a handle-request
method for it. Integrating your machinery in with the rest of our
component based system could also be done by having defpage define
html-element types (our base component class). There are of course
details that would need to be worked out.
I do like your (my ... binding macro alot. We have been thinking of
implementing a chainable binding mechanism that handles both getting
and setting the bound elements, but we haven't had an oerwhelming need
for it yet.
--
Craig Brozefsky <·····@red-bean.com>
Free Scheme/Lisp Software http://www.red-bean.com/~craig
"Hiding like thieves in the night from life, illusions of
oasis making you look twice. -- Mos Def and Talib Kweli
Craig Brozefsky wrote:
>
> "David J. Cooper" <·······@genworks.com> writes:
>
> >
> > To what extent does the above paragraph dictate how applications must
> > be written to work with the web server interface component? We have a
> > language for doing web apps:
>
> I don't understand the question really, since I don't see how the
> above paragraph can dictate anything, but I'll assume that you are
> asking how much does the basic webserver shim assume about the
> application on the backend.
Yes, that's really what I was trying to ask. Sorry for talking in riddles.
Your answer answered the question I was asking, thanks.
> Our html generating macros are underdeveloped (but there) in
> comparisons to cl-http since we primarily use templates, and our form
> processing is not based on cl-http presentation types, which we do not
> really support,
>
We don't use cl-http presentation types (W3P) either.
We plan to implement the concept of "writers" and "companions"
(a la ICAD/IDL and I believe Flavors) for defining (potentially)
different "views" (writers) on an object (e.g. an HTML view,
perhaps an XML view, postscript view, etc.)
Does anyone know where the "writer" and "companion" terminology
originates?
So the ":write-html-sheet" method would not necessarily be baked
directly into the page object defined by defpage -- rather, you
would have a "companion" to the page object to define the particular
writer method(s) for that object for that view (writer).
>
> so moving your system over would require migrating
> alot of cl-http code perhaps, or reproducing it. But as far as just
> talking to it, define a new application class and a handle-request
> method for it. Integrating your machinery in with the rest of our
> component based system could also be done by having defpage define
> html-element types (our base component class). There are of course
> details that would need to be worked out.
>
Sounds good. We might get away without actually rewriting all that
much stuff. We'll see, when one of us has a chance to look into it.
>
> I do like your (my ... binding macro alot. We have been thinking of
> implementing a chainable binding mechanism that handles both getting
> and setting the bound elements, but we haven't had an oerwhelming need
> for it yet.
>
Note that this is the concept used by ICAD/IDL (with "the") and other
KBE languages (e.g. Technosoft AML, the old Wisdom CML(?)). We support
"my" since "the" would be shadowing "common-lisp:the"
Anyway, I think I should get some of this stuff cleaned up and actually
made available on sourceforge before rambling on about it any more here...
-dave
--
David J. Cooper Jr, Chief Engineer Genworks International
·······@genworks.com 5777 West Maple, Suite 130
(248) 932-2512 (Genworks HQ/voicemail) West Bloomfield, MI 48322-2268
(248) 407-0633 (pager) http://www.genworks.com
I have tried to compile "uncommonSQL"
After "make" it generates me an "usql-library.x86f" which
I've tried to load into lisp with (load "usql-library")
But I get following error:
Error in function C::BYTE-INTERPRET-BYTE: Unbound variable:
SQL-SLOT-VALUE
The same error occurs when I try to load the binary of the
debian-package!
What's going wrong?
--
sincerely yours,
Jochen Schmidt
···@dataheaven.de
http://www.dataheaven.de