On Sun, 09 Dec 2001 18:24:24 +0100, Stefano Mazzocchi <[EMAIL PROTECTED]> wrote:
> Ovidiu Predescu wrote:
>
> > 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.
>
> This is an interesting concept: it would allow back compatibility as
> well as back-compatible support for publishing-oriented mindsets. But
> allow us to increase the functionality without turning the sitemap into
> a full-blown programming language.
Yes, that's right, by having the sitemap interpreted by a high-level
language allows us to extend the semantics very easily.
> > 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.
>
> I'm *very* interested to see the results of this, althought, IMO, there
> is no portable way to implement continuations in Java, but I'd *really*
> love to be proven wrong. (GNU Kawa, a scheme2java interpreter implements
> continuations only locally and uses exception throwing for that, but no
> global continuations are implemented)
To be implemented, continuations require access to the call stack. A
continuation object essentially contains the call stack. There's no
way to implement continuations in Java, as you don't have access to
the stack frame. Even in C, if you use the machine stack frame to
maintain the call stack of the Scheme functions (e.g. each Scheme
function is compiled in a C function), to implement continuations you
need to copy the machine call stack. This is non-portable across
machines.
To implement continuations in a portable way, you need to have access
to the stack trace. SISC does it by explicitly maintaining the stack
trace itself. The Scheme functions are not translated in Java methods,
as GNU Kawa and other implementations do it.
> > 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.
>
> Hmmm, I'm not thrilled by this at all: it might be good for *us*
> developers to experiment with this easily (I totally agree with that),
> but as I wouldn't want to turn the sitemap into a full blown programming
> language and give users full power to modify it (see my past messages
> against dynamic pipelines), I think we should "tune" the flow-driving
> expressing logic in such a way that you have what you want, is fully
> documented and you don't have to reinvent the wheel everytime.
Let me be clear: I don't propose to have the sitemap a program written
in Scheme. Rather the sitemap becomes data which is read by the Scheme
engine and interpreted accordingly.
Somebody can change the syntax and semantics of the sitemap by just
writing another interpretation of the data read in by the Scheme
engine.
> The rule is always to give all the freedom that one needs, but nothing
> more than that.
That's right.
> > Regarding the XML syntax of the sitemap, I actually believe it's a lot
> > easier if we just have the sitemap written in Scheme
>
> I think not. DSSSL vs. XSLT is a good example of why the lisp-like
> parenthesis syntax in the document-centric world is a bad idea.
All right, we'll continue to have the sitemap written in XML as today
;-).
> I would say the opposite: use XML even for describing the flow-driving
> logic.
Not sure about this.
> [Scheme vs. XML syntax deleted]
>
> But I don't think that a scheme-version of the sitemap would be of any
> good. Rather, I think it would ultimately hurt both the acceptance of
> the sitemap concept, its readability and its usefullness as a new
> instrument for web-app design.
OK, as I said above, the sitemap will continue to be written in XML as
today. Too many people prefer the XML syntax.
> > "sitemap" above is just a Scheme function that reads its arguments and
> > generates another function to match a request against the specified
> > patterns.
>
> IMO, this only proves that it would be easier and more immediate to
> transform the sitemap document into Schema syntax than it would be to
> java syntax. In fact, it might be a good solution for the interpreted
> sitemap: transform it to Scheme and let the scheme interpreter interpret
> it instead of writing our own.
Yes, that's exactly how it will work. The XML representation of the
sitemap will be translated to a Scheme representation, which is then
interpreted by the Scheme engine.
> > 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.
>
> This is behavioral and is nothing related to the syntax used. In fact,
> we all agreed that an interpreting engine for the sitemap semantics
> would allow faster development cycles and probably allow to reduce
> verbosity, as you state above.
>
> But please understand that this is not related to the syntax used to
> describe the sitemap semantics: one concern is the syntax, another
> concern is the semantic.
>
> In fact, we could imagine to have two different syntaxes for the same
> semantic, just like you can have two different styles for the same
> content.
That's exactly right.
> For the web-app flow-driving logic, the use of an XML syntax might be
> overwelming, expecially since escaping '<' with '≶' totally destroys
> readability. So I'm open to suggestions on that side.
>
> Still, it might be understood that the concer of coming up with the
> required semantics and the syntax used to describe it are two different
> concerns and must be kept well separated: in theory, there is nothing
> that prevents us from writing this flow-driving logic in java and add
> continuations support transparently, for example
>
> public class Addition extends WebApp {
> public execute(Environment env) {
> Results res = env.input("/webapps/addition/firstAddend");
> int a = res.getInt("addend");
> env.context.add("firstAddend");
> res = env.input("/webapps/addition/secondAddend");
> int b = res.getInt("addend");
> env.context.add("secondAddend",b);
> env.content.add("result",new Integer(a + b));
> env.output("/webapps/additon/result");
> }
> }
>
> and let Cocoon take care of the continuations.
>
> Anysay, syntax aside, the only portable way I see for implementing these
> types of continuations with java is a massive use of threads. This means
> that each running web-app (that is, each connected user if we ignore
> window-cloning), must have a stopped thread on the server side awaiting
> to be resurrected.
>
> Now: writing a webapp using page-driven programming is inherently *MUCH*
> harder (unless one totally ignores the issues with the back-button and
> the window-cloning, which is what normally happens), but at the very
> least, doesn't require "ONE THREAD PER LIVE SESSION"!!!, something that
> would bring on its knees even the most scalable JVM implementation. Not
> even talking about those OSes where thread==process (like Linux).
>
> The other solution (which is much more scalable) is to implement some
> native code that is able to save the complete state of the thread in
> some way, then free the thread to be used for other things. When the
> request comes, this thread-state data is used to 'resurrect' the thread
> from the point it was stopped (which is the same concept of
> 'call-with-continuations' in Scheme).
>
> Scheme shows it's possible to achieve, but for sure, this is not
> something the current Java language includes as a first-class citizen
> (and there are no JSR that proposed this, AFAIK)
>
> The best solution would be to add some continuation-based thread
> construction mechanism to Java, but this would require hard-core native
> code and I personally wouldn't even know where to start :(
You cannot have continuations as first class objects in Java, at least
not with the current definition of the JVM. No JSR will ever be able
to modify this. Continuations are not something you can build in a
Java library, you need to have support for them at the language
implementation level. See my description above on how continuations
are implemented.
You can implement continuations the way you describe above, but it's a
very expensive implementation.
The way the Scheme SISC engine implements it is by maintaining full
control of the stack of call frames. This is both portable and
efficient in terms of resources consumed. It's a bit slower than using
the Java VM to maintain the call stack, but not too bad.
The conclusion is that the Java code you wrote above as example cannot
be written, because you cannot have a magical Environment Java class
to implement the input() and output() methods.
You would have to write that logic in Scheme to be able to take
advantage of continuations. Now I know that people will not want to
learn Scheme to implement their high-level logic in it. That's why I
proposed in a message a week ago, to have an interpreter in Scheme for
a language like Javascript, or even Java. This interpreter would
extend the Java/Javascript language with primitives that hide the
continuations stuff. For example we could have send_response()
function to send the response, plus other functions to control the
lifetime of the current continuations.
A familiar language would make people more confortable to implement
their logic. However it could be a lot of work for us to implement the
interpreter.
Best regards,
--
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]
