Berin,
On Sat, 08 Dec 2001 17:11:38 -0500, Berin Loritsch <[EMAIL PROTECTED]> wrote:
> Ovidiu Predescu wrote:
>
> > Excellent, this is the Scheme engine I was looking for!
> >
> > All the engines I knew from a long time ago where written in C, not in
> > Java. With these engines interfacing between Scheme and Java had to go
> > through a C layer implementing JNI calls, which, as you imagine, is
> > very expensive.
>
>
> PLEASE NOTE:
>
> JESS != Scheme
>
> JESS is an Expert Shell system that uses a syntax that is suspiciously
> similar to Scheme. However at it's core is the RETE engine. This is
> the rules based engine that performs better than traditional
> if/then/else tests.
I know is not, but with a Scheme engine we can implement the rule
system you're talking about. The rule system JESS has, or the Prolog
engine Jason Foster mentioned, can be implemented easily in Scheme.
The trick was to find the right Scheme engine that can do the job. The
old ones I played with in the past were all standalone, C
applications. The Java ones I was aware of were either not fully R5RS
compliant (which in most cases means they didn't implement
continuations), or were too slow. Michael Hartle's pointer was
invaluable, as SICS is exactly the engine I was looking for. I was
able to implement this morning a simple servlet that runs the SICS
Scheme interpreter and evaluates things on request. I'll work on it to
implement the current sitemap semantic, which should be quite easy to
do, once I figure out how to export Java objects to Scheme. I also
want to hook up the Scheme servlet to Emacs, so I can evaluate in the
servlet the Scheme code I'm entering in Emacs, by just typing M-C-x
(Alt-Ctrl-X for non-Emacs users). At that point I'll have a very
powerful development environment, with no painful Java rebuilds and
Tomcat restarts ;-)
Anyways, here's the way I see now the whole thing right now. The
sitemap continues to be the main controlling point. However, the
result of a matching will no longer be a pipeline, but a Scheme
function invocation. In particular, a pipeline will be defined as a
Scheme function.
The result of this is that you can have the todays pipeline concept
unmodified, so it should be easy for people to understand how things
work. This processing model would fit very well applications that
publish content more or less static, which needs to be transformed in
various ways.
For more complex applications, multi-page type apps, you can hookup
your own function that will be called once a match is performed. This
function will implement your application high-level logic, using
Scheme continuations. The application logic (connecting to databases,
performing computations and so on) will be written in Java as
normal. In Scheme you will only describe the navigation between pages,
using the continuations paradigm.
Each time you want to send a response back to the client, you will use
a "send-response" function, which takes an output pipeline definition
and an XML document to process.
We can experiment with rule based systems as well. The beauty of
having such a high-level, interpreted language, driving the processing
is that we can experiment with lots of ideas very easily. Since the
whole sitemap logic is written in Scheme, it's very easy to alter it
the way you want it.
Regarding the XML syntax of the sitemap, I actually believe it's a lot
easier if we just have the sitemap written in Scheme, instead of
XML. We can add new stuff much more easily than trying to invent a
syntax in XML. Here's how a sample sitemap would look like in the
Scheme syntax:
(sitemap
(define-pipeline docbook-html (dir filename)
(generate (concat dir filename))
(xslt "docbook-html.xsl"))
(match "/myapp/*/*.xml"
(pipeline docbook-html))
(match "/app2/*/*.pdf"
(pipeline
(generate (concat dir filename))
(xslt "docbook-html.xsl")))
)
"sitemap" above is just a Scheme function that reads its arguments and
generates another function to match a request against the specified
patterns. Another side-effect of executing "sitemap" is that all the
"pipeline" functions will setup in the Java space the transformers
objects according to the description. The serialization process could
be added automatically by the "match" functions, if no serializer has
been defined. Similarly one can think of lots of possible semantics
associated with the above description.
Of course, he sitemap file should contain no Scheme code, only the
sitemap description. Everything else should be in separate Scheme
files.
I don't think the Scheme sitemap syntax is that bad, but I'd be
curious to know what others think of it.
I'll let you know what's the progress on my work. If anyone is
interested in seeing intermediate results, I can check the code in the
scratch-pad CVS area.
I'm really excited about the new possibilities, so I'm going back to
coding some more ;-)
Cheers,
--
Ovidiu Predescu <[EMAIL PROTECTED]>
http://orion.nsr.hp.com/ (inside HP's firewall only)
http://sourceforge.net/users/ovidiu/ (my SourceForge page)
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
