cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: initial checkin of the Scheme code
Date Tue, 11 Dec 2001 00:00:12 GMT
just some over-the-head comments from a community-leadership
perspective:

Ovidiu Predescu wrote:
> 
> Hi,
> 
> I've just checked in the initial code for the Scheme integration. It
> is in scratchpad/schecoon/ (for lack of a better name) in the main
> trunk.

Let me state this loud and clear: we should all work together to avoid
having forking friction developping inside Cocoon.

I love the scratchpad idea where committers can present their ideas and
work on them in the public, I think it's a great thing and should not be
regulated at all (means that you can add your own stuff as you like
overthere) but you need a formal votation to move things from there to
the main trunk.

I state this even if it's obvious so that everybody knows this and it's
crystal clear.

Mixing XML+Java+Scheme has not been tempted before, ASAIK, and as we've
seen, it's potentially explosive mix of feelings to hurt.

At the same time, I think all Cocoon 2.0 users understand that if you
can find natural to program a publishing system with an XML file (the
sitemap), programming the flow of your application using a scripting
language is not that distant from that same concept.

Moreover, now that we clearly identified the SoC between
syntax/semantics and many examples showed that the same semantics could
be equally expressed with different syntaxes, it's good that we now
concentrate on the semantics and let the syntax be the last of our
concerns.

In theory, if one likes, we could make the syntax wrapper pluggable, so
that you could write your flow-driving code with the syntax you like the
most (or it best fits your favorite IDE)

This said, I'm *very* interested in the 'semantics' that Ovidiu is
playing on because I think it would give Cocoon a potentially giant
expressive power compared to all other server-side java-based solutions,
and I'll keep a neutral (and tollerant) position to the syntax that he
will use to prove these concepts useful.

I kindly suggest all of you to do the same.

If the concept proves to be successful from a semantic point of view,
we'll debate over which syntax is better, or we'll make it possible for
everybody to use the most liked syntax, but this is not something we
should debate on until the concepts are fully expressed, outlined and
tested.
 
> As it is right now, it doesn't do much. There are two servlets,
> REPLServlet and REPLEvalServlet. The first one is supposed to be the
> main entry point for the new Scheme-driven Cocoon. Eventually it will
> execute the Scheme function that will execute the sitemap.
> 
> The second servlet is used for development only. It is mounted as
> /schecoon/eval under the servlet, and it accepts POST messages
> containing Scheme code to evaluate. Because this servlet is a security
> risk, you need to configure a flag in web.xml to enable it. Once this
> flag is set to true, the servlet is setup to use basic
> authentication. To set this up with Tomcat 3.3 for example, add the
> following entry in conf/users/global-users.xml:
> 
> <user name="cocoon" password="your password" roles="cocoon_admin"/>
> 
> There is a command line driver for the interpreter in the util
> package. This will read in an infinite loop a Scheme expression from
> the command line, POST it to the servlet and print out the
> response. This application is intended to be used with Emacs, read the
> README file in the emacs/ directory. From within Emacs, you can edit
> your code, and when you want to test it, you type few keys which will
> send the code to the servlet Scheme engine to be evaluated.
>
> The SISC jar file is built from the latest sources in CVS. With the
> simple servlet I've just described above, it adds less than 2Mb to the
> runtime memory.

I'll dive into that tomorrow.

Many thanks for doing this :)

-- 
Stefano Mazzocchi      One must still have chaos in oneself to be
                          able to give birth to a dancing star.
<stefano@apache.org>                             Friedrich Nietzsche
--------------------------------------------------------------------



---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org


Mime
View raw message