On Mon, 10 Dec 2001 12:46:15 +0100 (CET), Torsten Curdt <[EMAIL PROTECTED]> wrote:
> > OK, we'll stay with the XML syntax for the sitemap.
> >
> > > I'd also like to see the flowmap to have XML syntax. I'm still dreaming
> > > of developing some visual tools for editing this stuff. This would
> > > be WAY easier when everything is XML based!!
> >
> > The flowmap is actually nothing more than a program that drives the
> > navigation between pages. Because of that a programming language is
> > much more natural to express the logic, than XML.
>
> But isn't the sitemap (at least in some parts) programming, too?
> "programming in XML" - does it really taste so bad?
> IMHO it depends on the level of abstraction.
The current sitemap yes, it mixes content transformation with
programming. The sitemap I envision is different, it specifies only
URL mappings and content transformation. All the control flow between
various pages is done in a real programming language.
> Question is: do we want to express the logic in a component based
> approach like the sitemap does or do we want a full blown scripting
> language where we can do everything we want?
I think the current sitemap is a mess, and very hard for people to
understand. There too many things it tries to do. We still need the
sitemap to do dispatching, and specify pipeline of transformation. But
we need a programming language to express the flow between pages. (I
don't like the term scripting language, they are programming languages
as well, in same cases more powerful than the "real" programming
languages - Java, C++, C etc.).
> If we have a set of well defined components to express the flow
> we could stay with XML. If not XML wouldn't make much sense
> here. So _this_ is the question that really relates to the question
> of XML syntax.
I strongly believe we need a programming language to express the
control flow. XML is just not the right choice.
> How much freedom in terms of program logic do we really need
> to give inside the flow? That's what we should decide first.
> Is it really necessary to have this way of scripting if we also
> have actions? What about calling actions from the flow? Can't
> _they_ do the dirty work where programming is really needed?
No actions. They were invented to solve the problem a programming
language with continuations solves.
> In cocoon everything is XML to the bone. Do we really want to give
> this up? There is already a sitemap editor at sourceforge. We could
> have flowmap editor then, too. If we say flow is completely scripting
> this will not happen.
You don't need a flowmap editor, any text editor will do it, if the
language has a natural syntax. If the syntax of our language is close
enough to an existing language, we can even take advantage of existing
editors or Emacs modes.
I haven't played with the sitemap editor, so I don't know what it
does.
> And don't get me wrong I don't want to be the stopper saying "no,
> that's new" - but I'm trying to ask some (maybe) unpleasant questions
> just to make sure we are going the right direction.
Thanks ;-). I also want the unpleasant questions to be asked
before. They are a good reality check. So please continue to ask them!
> Although I often wished to have scripting for exactly what seems
> to became reality now - I am a bit reserved.
I'm a bit enthusiastic, so I guess you'll be a good
counter-balance. Please continue to be until you see some more
concrete results.
> > > Ovidiu, could you give a more complete example how these implicit
> > > flow definition could look like for a more complex multipage form?!
> > > (I'm still sceptic about this approach - still like the turing machine)
> >
> > Here's a simple example adapted from one of the papers I pointed
> > to. I'm using a syntax more familiar, not actual Scheme.
>
> When really talking about scripting I guess I'd prefer to
> see JavaScript as scripting language. I bet this would be quite pleasing
> for webapp/website builders...
For a more complex example, please check a reply to a message to
Berin.
> > In this example you have three pages. The first page prints some text
> > and asks for the first number. The second page prints out the first
> > number obtained from the first page, and asks for the second
> > number. The third page displays the two numbers and the result.
> >
> > The text for each page is written in three different XML files. Each
> > file is processed through a pipeline that takes the XML doc and
> > generates the output. The send-response() function is responsible for
> > doing this processing. It takes the page to process, the pipeline name
> > that processes the page, and an optional data structure that contains
> > data which could be used to generate the pages.
> >
> > The send-response function is special. After it sends the response to
> > the client, it suspends the execution of the thread serving the
> > request. Before doing this, it stores the continuation of the
> > procedure in an internal hash table. This hash table contains as keys
> > URLs, and as values continuation objects. When a particular URL is
> > invoked, the Scheme engine obtains from the hash table the
> > continuation object and executes it. The net effect is that the
> > suspended function continues the execution right were it was.
>
> This is again one thing that scares me ... how will this thing
> scale!? A whole thread for a person - waiting for the next one?!
No, please read my reply to Stefano's message. I explained there how
the Scheme engine is implemented. Essentially the Scheme engine
maintains its own call stack, it doesn't rely on Java's VM to do
it. This way it can package the call stack, program counter and
variable values in a continuation object. There is no thread being
associated with a continuation object.
> > To be able to correctly specify in the generated HTML pages what is
> > URL to invoke next, send-response() makes available to the pipeline
> > the continuation URL. During the processing of the file, various
> > transformers can make use of this URL to embed it in the generated
> > result page.
> >
> > To be able to incorporate URLs to older points in the processing, the
> > send-response() function could return as value an object that contains
> > the URL to its continuation. You can pass this URL in the optional
> > dictionary, as an additional argument, if you wish so.
> >
> > function addNumbers(HttpRequest request)
> > {
> > send-response("first-page.xml", "my-pipeline");
> > first = request.getIntParameter("first");
> > send-response("second-page.xml", "my-pipeline", {"first" = first});
> > second = request.getIntParameter("second");
> > result = first + second;
> > send-response("third-page.xml", "my-pipeline", {"result" = result});
> > }
>
> Hmm... ok let's try with XML:
>
> <flow starts-with-state="first">
> <states>
> <state id="first" uri="first-page.xml"/>
> <state id="second" uri="second-page.xml"/>
> <state id="third" uri="third-page.xml"/>
> </states>
>
> <transitions>
>
> <transition id="goToSecond">
> <action type="RequestParameter">
> <parameter name="first"/>
> </action>
> <next-state id="second">
> <parameter name="first" value="{first}"/>
> </next-state>
> </transition>
>
> <transition id="goToThird">
> <action type="RequestNumbers">
> <parameter name="first"/>
> <parameter name="second"/>
> </action>
> <action type="addNumbers">
> <parameter name="first" value="{first}"/>
> <parameter name="second" value="{second}"/>
> </action>
> <next-state id="third"/>
> <parameter name="result" value="{result}"/>
> </next-state>
> </transition>
>
> </transitions>
> </flow>
>
>
> Hm.. I have to admit your example feels much more natural :-\
I'm glad you admit that ;-)
> > In this example each send-response has its own URL. The default URL
> > which selects the addNumbers() function is specified in the
> > sitemap. The newly generated URLs for each send-response() function
> > have unique URLs, which possibly are derived from the initial URL
> > (still need to decide on the format).
> >
> > If the user uses the back button in the browser, he/she will select a
> > page that has URL pointers to old continuations. When the "submit"
> > button is pressed, the user effectively selects an old continuation
> > object, at a point in the program that was executed in the past.
>
> But you don't want to have a thread per continuation object, don't you?
> I wonder if it would be possible to see a continuation as a little VM
> that has an evirionment (registers etc.) and a programm pointer.
>
> If we could only safe those information (the environment and the
> position inside the continuation). I bet this would be more scaleable...
>
> (or did you take this approach for granted ;)
The Scheme does exactly that.
> > You can control for how long the continuations are kept around, aka
> > for how long you allow the user to go back in the processing, by
> > simply modifying the continuation object. We can specify a default
> > timeout for all the continuation objects which are created, and have a
> > function that modifies this default.
> >
> > Here's an example of how one can change the expiration time of a
> > continuation:
> >
> > set-default-expiration (60m); // Set expiration time to 60 minutes
> > continuation = send-response("some-page.xml", "some-pipeline");
> > continuation.setExpire(0); // Expire it now!
> >
> > The above example was a very simple, and doesn't justify why one would
> > use continuations instead of describing the flow in a FSM, or even
> > spreading the logic across multiple pages.
> >
> > However the language you implement the page flow into is complete: it
> > has loops, conditionals etc. You can implement as complex of a logic
> > you want, depending either on the values of parameters present in the
> > request, or on values obtained from your low-level logic. The language
> > also allows you to call arbitrary Java objects, which implement the
> > logic of your application.
> >
> > I hope this example makes you understand why this approach is much
> > easier to implement Web applications. I'm sure many of the things I've
> > described above may change over time, as we implement things, expose
> > it to users, and get more feedback on useful things to have. So don't
> > take things too literaly, I've just tried to give you a taste of the
> > idea.
>
> You are for sure tempting me :)
All right!! Now I just need to go back to implementing it...
Best regards,
--
Ovidiu Predescu <[EMAIL PROTECTED]>
http://orion.rgv.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]
