It is a pretty common need these days to develop applications
which use a web browser as the user interface.
We've seen lots of requests on the newsgroup about it.
And of course, this is just the Lisp newsgroup, there is
a huge amount of this activity being done using non-lisp.
The demand for these applications will only continue to grow.
My opinion has been that an object oriented Lisp is ideal for
applications in this domain.
There are lots of reasons why this is so, which I've described
before, and so will just sum it up as productivity and maintainance:
these apps must be developed in many cases weeks, not years
and must be changed constantly. Lisp features play well here.
A key aspect of these web applications is fast access to
persistent data. RDB's are usually not fast enough for the human
real-time nature of dynamic web page generation.
Moreover, RDB's are very poor at dealing with changes in
the data model. Object databases are the right technology,
but the C++ object databases are stuck with the static C++ development
methods and a low-level language that is a poor fit to higher level
programming using HTML generation.
Over the last 2-4 years with some support from Franz, Inc.,
I've been focused on developing a
system which applies the power of Lisp to this domain.
A high performance persistent dynamic object system is central.
In addition, a high-level "scripting" language that is designed
for dynamic HTML generation is also important. Perhaps most important
for success as a software product is that this language be
attractive to "conventional" or non-lisp programmers.
As many know, I have started a new company, IntelliMarket.Com, Inc.
that continues to pursue the promise of this technology.
We have made a lot of progress. We are actually
using this technology in the real world for at least one client.
I'm posting this message because I think its about time to
find some others that can also profit from this technology.
In particular, our object database, IntelliStore (tm), is
just about ready for a few alpha users. It is very similiar
to AllegroStore, which in turn, is similiar to Statice.
If you think you might benefit from this technology, and
want to be an early adopter, please send me email and
we can talk about what your doing and how we might work together.
-Kelly Murray ···@intellimarket.com
On Sun, 25 Oct 1998 17:11:56 -0800, Kelly Murray
<···@IntelliMarket.Com> claimed or asked:
% If you think you might benefit from this technology, and
% want to be an early adopter, please send me email and
% we can talk about what your doing and how we might work together.
For myself, I can forgive the advertizement :-)
But, I should warn you of the things to watch out for. I have been
down this road as an end user and have seen bad implementations of
good ideas. Well, I have experience with two.
The first one is an obscure language called Meta-HTML. The company I
work for is still using it. I don't know for how much longer. It
provides a great deal of flexibility in page generation.
Unfortunately it is dog slow. A lot of iron has been thrown at it to
get the required page delivery rate. Another problem is that the
Meta-HTML tags clutter up the HTML that is static. This makes page
design and modification a PITA. To access back end services, we've
had Meta-HTML hitting CORBA services in ways that would turn your hair
white. Don't worry though. Your hair would fall out shortly
thereafter.
The second one is Active Server Pages. Microsoft actually has a
pretty good thing going here. It is much more performant than
Meta-HTML, but less flexible. ASP would probably be pretty good
except for a couple of points. The most glaring problem is VBScript.
If you thought VB was a crippled language, you should see VBScript.
However, it can use COM. That is in fact what it is for. Personally,
I prefer the power of ActiveState's port of PerlScript which rides on
Perl for Win32. It gives ASP a respectable scripting language.
Especially since ASP allows multiple scripting languages in a page.
ASP will also cache pages for performance, something Meta-HTML does
not do.
While PerlScript gives ASP some flexibility, it suffers from being
somewhat slower and people at my company won't touch it. That leaves
COM to do all the real work. I won't go into the limitations of COM.
It is just too sad for me to think about right now.
There are other technologies popping up. Java Server Pages is one. I
haven't had a chance to look at it yet. I don't know how it differs
from servelets. I also haven't had a chance to look at CL-HTTP,
although I certainly plan to.
The way I see it, if you are going to go with a scripting language in
a Lisp environment, it might as well be Lisp. Imagine Lisp in the
place of VBScript in ASP. Now you have some real potential. Now you
just need a fast data source. If you can beat Oracle, you really have
something.
--
David Steuber (ver 1.31.2a)
http://www.david-steuber.com
To reply by e-mail, replace trashcan with david.
"Ignore reality there's nothing you can do about it..."
-- Natalie Imbruglia "Don't you think?"
David Steuber The Interloper wrote:
>
> On Sun, 25 Oct 1998 17:11:56 -0800, Kelly Murray
> <···@IntelliMarket.Com> claimed or asked:
>
> % If you think you might benefit from this technology, and
> % want to be an early adopter, please send me email and
> % we can talk about what your doing and how we might work together.
>
> For myself, I can forgive the advertizement :-)
>
> But, I should warn you of the things to watch out for. I have been
> down this road as an end user and have seen bad implementations of
> good ideas. Well, I have experience with two.
It should be clear I believe I've got a good implementation
of a good idea. The request for a few others to work with it
will be helpful in finding out. I know it works for me.
Meta-HTML is basically LISP with <>s replacing ()s.
It lacks an object system, and therefore a persistent object system.
> The company I work for is still using it.
> Unfortunately it is dog slow.
Then you're company would be a good potential customer ;)
> The way I see it, if you are going to go with a scripting language in
> a Lisp environment, it might as well be Lisp. Imagine Lisp in the
> place of VBScript in ASP. Now you have some real potential. Now you
> just need a fast data source. If you can beat Oracle, you really have
> something.
Well, SilkScript basically IS Common Lisp (just don't tell management ;)
And so it compiles into native machine code like C++.
But it's not just lisp because it is much MORE than that, and also
because it much LESS than Common Lisp to make it easy to learn.
-Kelly Murray ···@intellimarket.com
On Tue, 27 Oct 1998 18:16:45 -0800, Kelly Murray
<···@IntelliMarket.Com> claimed or asked:
% It should be clear I believe I've got a good implementation
% of a good idea. The request for a few others to work with it
% will be helpful in finding out. I know it works for me.
Not having seen your product yet, I can't comment. But to do worse
than my two examples would be quite a trick.
% Meta-HTML is basically LISP with <>s replacing ()s.
% It lacks an object system, and therefore a persistent object system.
Meta-HTML is worse than that. It is an extremely crippled language
that only vaguely resembles lisp, even when you change the angle
brackets back to parens.
% > The company I work for is still using it.
% > Unfortunately it is dog slow.
%
% Then you're company would be a good potential customer ;)
The possibility exists. I know that we are looking for an alternative
to Meta-HTML in my group. My fear is that it will be ASP since a
couple clients are getting products on that system. Also there are
Microsofties around the company.
Since we are now wholly owned by Reuters, there is a lot more red tape
involved with implementing new systems. I seem to have less freedom
than I used to have. Still, you might be able to impress me enough to
put my neck on the line and try to push your technology.
How about contacting me at my work address so we can discuss this
further? It is dsteuber at moneynet dot com. Since Universal
Access has apparently ceased to be, it would also help to have some
assurance that that won't happen with you :-).
We have the Meta-HTML source. I'm not sure that is enough to salvage
that idea. Anyway, one thing I dislike about it is how the code
completely messes up the HTML. ASP is just as guilty in my opinion.
% Well, SilkScript basically IS Common Lisp (just don't tell management ;)
% And so it compiles into native machine code like C++.
% But it's not just lisp because it is much MORE than that, and also
% because it much LESS than Common Lisp to make it easy to learn.
The other obstacle to overcome is the fact that people at my company
don't seem to like lisp. Well, a lot of them don't. There are some
ex-lispers who reminisce about the good old days. One guy worked with
a Xerox lisp system that he says was far superior to the latest tools
we have for C++ development.
Contact me at work (I am a peon there, so I can't just force anything
on anyone). We can talk about this privately.
--
David Steuber (ver 1.31.2a)
http://www.david-steuber.com
To reply by e-mail, replace trashcan with david.
"Ignore reality there's nothing you can do about it..."
-- Natalie Imbruglia "Don't you think?"
········@david-steuber.com (David Steuber "The Interloper") writes:
> The first one is an obscure language called Meta-HTML. The company I
> work for is still using it. I don't know for how much longer. It
> provides a great deal of flexibility in page generation.
> Unfortunately it is dog slow. A lot of iron has been thrown at it to
> get the required page delivery rate. Another problem is that the
> Meta-HTML tags clutter up the HTML that is static. This makes page
> design and modification a PITA. To access back end services, we've
> had Meta-HTML hitting CORBA services in ways that would turn your hair
> white. Don't worry though. Your hair would fall out shortly
> thereafter.
I like Meta-HTML. It pretty much follows the functional programming
idea. We use 5.06 on our company site and it seems quite quick. I've
designed a set of custom tags and a set of Meta-HTML macros to
interpret the tags and then generate our catalog pages from a database
using those tags, in an XML fashion. Page design and modification is
easy, just change the tag definitions. Try
http://www.mhhe.com/catalogs/activity-1255.mhtml for an instance.
What version are you using?
You might look at http://www.morphtech.com/morphtech for another
lisp-like approach.
On 27 Oct 1998 22:42:27 -0500, Richard Tietjen
<········@kale.connix.com> claimed or asked:
% I like Meta-HTML. It pretty much follows the functional programming
% idea. We use 5.06 on our company site and it seems quite quick.
I think we are using 5.06. It might be just 5.05. The slowness of
the thing might be the fault of our programming rather than the mhtml.
Then again, every page hit causes a rather lengthy sequence of
operations. The engine is resident at all times thanks to fast-CGI.
But it still goes and loads engine.conf (which has a lot of variables
set) along with other files, parsing and evaluating as it goes. That
may be fine for development because you can make quick changes. But
for production, I would want the code compiled. Also, fast-CGI is
still slower than an http server that is up all the time to deliver
pages. The nph-mhtml? daemon doesn't seem to be the answer.
Some things in Meta-HTML are pretty slick. But most of it is painful.
I really hated writing code to deal with a CSV format file from
another server in a general way. I ended up with something even
uglier than a Perl hash that did basically the same thing to retrieve
the values. Yuck.
Mind you, if the problem is due to bad programming on our part, then I
guess no system will work well.
--
David Steuber (ver 1.31.2a)
http://www.david-steuber.com
To reply by e-mail, replace trashcan with david.
"Ignore reality there's nothing you can do about it..."
-- Natalie Imbruglia "Don't you think?"
> On 27 Oct 1998 22:42:27 -0500, Richard Tietjen
> <········@kale.connix.com> claimed or asked:
>
> % I like Meta-HTML. It pretty much follows the functional programming
> % idea. We use 5.06 on our company site and it seems quite quick.
My approach stole in my opinin the good parts of Meta-HTML,
which is the ability to keep using low-paid HTML programmers,
but still be able to do
more sophisticated dynamic webpages, but not the bad part,
which is writing programs using a funky <>'d language.
The idea is server-side extended html in which
the extensions are written in SilkScript.
Thus a xhtml document can do stuff like:
<freds-page-header name="products">
..standard-html-here..
And one writes the extension in silkscript:
(extend-html FREDS-PAGE-HEADER (name)
;; output the links to the other section names as anchors,
;; but make this one a non-anchor
(loop for section in (retrieve-section)
do
(if (equal name (section.name section))
then
(text name) ;; not an anchor
else
(anchor name name)
))
)
The xhtml document is then parsed and stored into the website database,
and when retreived by a browser, it executes the code to
generate the dynamic part and outputs the static part.
-Kelly Murray ···@intellimarket.com
In article <·················@news.newsguy.com>,
········@david-steuber.com wrote:
> The first one is an obscure language called Meta-HTML. The company I
> work for is still using it.
Isn't Meta-HTML influenced by Lisp?
> There are other technologies popping up.
Quite nice to use is SIOD (Scheme In One Day/Defun)
together with its template engine.
> Java Server Pages is one. I
> haven't had a chance to look at it yet. I don't know how it differs
> from servelets. I also haven't had a chance to look at CL-HTTP,
> although I certainly plan to.
CL-HTTP provides Common Lisp with some packages
with HTML constructs as Lisp functions/macros.
Your page code then is compiled Lisp. Since the URLs
are just objects which invoke compiled functions when requested,
speed is good.
Basically you export URL objects with a call to EXPORT-URL:
(http:export-url #u"/mail/info-mcl.html"
:mail-archive
:pathname "Macintosh HD:Rainer Joswig:Eudora � Lavielle:Mail
Folder:Lisp:Dialects:MCL:MCL Info"
:mailing-list ·········@digitool.com"
:title "INFO MCL"
:documentation "Macintosh Common Lisp."
:mail-file-format :eudora
:recache t
:default-view :conversation
:mail-archive-class 'http:indexing-mail-archive
:message-class 'http:indexing-message
:thread-class 'http:indexing-thread)
Typical code might look like this:
(defmethod ma-write-message-interval ((mail-archive mail-archive) view
stream start end)
(maybe-update-mail-archive mail-archive)
(let* ((ma-url (ma-url mail-archive))
(title (or (get-value ma-url :title) (name-string ma-url))))
(flet ((write-title (stream)
(with-centering (:stream stream)
(write-string title stream))))
(declare (dynamic-extent #'write-title))
(with-conditional-get-response (stream :html
:last-modification
(ma-cache-time mail-archive)
:expires
(expiration-universal-time ma-url)
:cache-control
(url:response-cache-control-directives ma-url)
:content-language (languages
ma-url))
(with-html-document (:stream stream)
(with-document-preamble (:stream stream)
(declare-title title :stream stream))
(with-mail-archive-document-body (mail-archive stream)
(with-section-heading (#'write-title :stream stream)
(msg-write-message mail-archive :archive-info stream)
(msg-write-message nil :horizontal-line stream)
;; Main loop that puts up messages
(loop for idx upfrom start to end
for msg = (ma-get-message mail-archive idx t)
do (with-section-heading ((msg-heading msg) :stream stream)
(msg-write-message msg view stream)))
;; Put up the archive signature
(ma-write-signature mail-archive stream))))))))
Where "with-conditional-get-response" writes the HTNL headers,
"with-html-document"
encloses the document in <html> </html>, etc...
> place of VBScript in ASP. Now you have some real potential. Now you
> just need a fast data source. If you can beat Oracle, you really have
> something.
Use a persistent object store. On the mac people are using WOOD, on Genera there
is Statice, PLOB! on a lot of platforms, ...
Or just load all objects in memory. I wrote some code which imported data and
created the "page" objects. These page objects could come in hierarchies which
take care of its dependant objects. Methods using method combination than
generate HTML code for these page objects. Once your page is a real object,
you can think about online live administration, automatic navigation
generation, instant
updates, instant log evaluation, ... Then you think about "services" your site
provides. These services then are command objects that can be invoked
by users. Users are represented as objects remembering which services have been
used, when, and how often. Etc. Etc.
Books can be relations over information items. These items then would belong to
concepts. Assemble documentation on the fly according to users interests,
instead precomputing huge mountains of legacy HTML code. "Interbook" is
such an example CL-HTTP application
(http://www.contrib.andrew.cmu.edu/~plb/InterBook.html).
--
http://www.lavielle.com/~joswig