cocoon-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Stefano Mazzocchi <stef...@apache.org>
Subject Re: [control flow] changes and new sample
Date Tue, 10 Sep 2002 09:19:20 GMT
Ivelin Ivanov wrote:
> 
> I have been following along the thread silently trying to finally "get" the
> picture.
> 
> At this point, the only reasonable question that I can ask is,
> if it is possible to consider providing the continuation capabilities within
> the Actions instead of promoting JavaScript as another language supported by
> Cocoon.

instead? no. I *want* the ability to describe the flow of my application
with a weakly typed and interpreted language.

This said, I would not be against the use of the continuation paradigm
for other parts of Cocoon, if that makes sense. Just remember that
compiled bytecode interpreted directly by the JVM can't have
continuations because java doesn't have that concept (and it's not
possible to add it without patching the JVM, which is not something we
can do).
 
> My reasoning is that for the size and scalability of the web applications
> that I am dealing with, I wouldn't bet too much on a loosely typed and
> non-compiled language.

These are two different things: it's entirely possible to think to have
a java 'emulation' layer that provides continuations (but I'm sure
performance would be horrible!). That would give you continuations for
your strong-typed code.

Or, we could think of a javascript compilation layer that is capable of
understanding how to save its own state as a continuation (don't ask me
how this could be done, though, I have no idea! hmmm, maybe thru
exception throwing?)

> If provided, however, I may seriously consider using
> a more sophisticated paradigm for flow control within my actions.

For sure, a most sophisticated paradigm for flow control requires some
level of indirection of your action bytecodes. And as far as performance
goes, I'm not sure that having part of the flow interpreted is going to
impact that much on performance. (note that business logic is performed
by java objects and resource creation is still performed by the normal
cocoon pipelines).

It's clear that I consider the flow layer a *much* better alternative to
actions in many senses and the performance impact of the interpretation
layer will have to be tested before using this as an argument.

This said, I'm entirely in favor of making it as simple as possible to
call actions from the flow layer or viceversa (even if I don't know
how). Just understand that in order to have continuations, we need an
interpretation layer on top of the JVM. This is a fact. So we can't
simply attach continuations to actions and forget about the flow.

I'm aware of the feeling that such a 'strange' technology provoques in
people (expecially java people that are used to live in their 100% pure
world), but please, let's try to be a little more flexible than this and
consider this just a try in an innovative direction and let's have the
community of users decide it's fate.

-- 
Stefano Mazzocchi                               <stefano@apache.org>
--------------------------------------------------------------------


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


Mime
View raw message