> What you're referring to is probably not session, but cookies. The > problem is you cannot use cookies to encode the continuation's URL, as
> If you look at the concept of session in the servlet environment, you > realize it's only a way to save state across HTTP requests. But with > The > problem is you cannot use cookies to encode the continuation's URL, as > this would prevent the user from hitting the back button. This happens > because the cookie is set globally, for the whole domain. Hitting the > back button will not change the cookie's value to point to the right > page. > So clearly you need a way to encode the continuation's URL in the page > itself, rather than assign it to a cookie. Hmm - I think there are two separate issues here. First, the back button/multiple browser problem. I think I remember Stefano referring to the "evil" back button, and even though Queinnec's papers tried to address it, I don't think it's necessary to force schecoon to use continuations in the same way. There are other ways to deal with the problem, e.g. disabling the offending causes. But if you did want to deal with the back/multi-browser problem with continuations, you wouldn't need a continuation URL stored in the page. Just some unique continuation ID (a hidden field say). All exits from a page would send this ID in the request for a new page. Before running the continuation you clone it (you can do this right?) in case another page tries to run the same continuation in a different direction. URL request parameters could even be used, e.g. foo.com/next?cont-id=4ff as one choice foo.com/finish?cont-id=4ff as the other. I just don't think hard-coded continuation URLs are a nice idea. So continuations aren't really being used in a similar way to session ID here (was this your point?)... using the same cont-id can branch the program in a different direction by sending a different request for that continuation, with the choice of next action logically named in the URL/some-other-request-param. There's only ever one continuation of a running program anyway (the current one). But this continuation can be branched in different directions, depending what's asked for. Whoops, Ovidiu's just landed on the list, so I'll carry on after... Allan -----Original Message----- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf Of Ovidiu Predescu Sent: 01 February 2002 02:51 To: Allan Erskine Cc: [EMAIL PROTECTED] Subject: Re: first impressions on continuations idea Hi Allan, [I've Cc-ed cocoon-dev, as I believe you bring up some good points.] On Fri, 1 Feb 2002 00:32:50 -0000, Allan Erskine <[EMAIL PROTECTED]> wrote: > Sorry this has been long in coming - it's really busy for me right now. No problem, it's been busy for me too. > But I've made my way through the papers you sent, and the relevant > threads - I really love it. I loved it too when I saw it the first time ;-) > For a start it plain old smacks of a good idea - anyone who's suffered > the indignity of having to code a web-app must surely weep at the > concise flow programs in Queinnec's papers. I definitely agree with you. > Secondly I love the idea that we can start to use higher-order language > features throughout the web-app development process. Instead of > HTML/XML/validation code/backend code/actions which is just > unmanageable. Yes, it's just a pain to do this, and Cocoon and all the other frameworks really suck in this respect. > So I'd be really interested in what you plan to do with this schecoon > web-app example. > > Starting with the example code you put up on cocoon-dev: > > Ovidiu said: > > > > Because of the continuations, the URLs for the second and third pages > > would probably look more like: > > > > http://foo.com/add/4ffds8454mfd90 > > Would a session not be the appropriate place to store continuations and > associated data? The URL strikes me as a really bad idea, as it should > be a logic-level address (ie foo.com/add) rather than an implementation > level (foo.com/add/4ff.) Under what circumstances might you wish not to > resort to session? This is a good question. If you look at the concept of session in the servlet environment, you realize it's only a way to save state across HTTP requests. But with continuations, you no longer need this! The continuation saves in it the complete stack frame of calls, including local variables. When a continuation is resurrected, it will contain the values for all the local variables you declare. What you're referring to is probably not session, but cookies. The problem is you cannot use cookies to encode the continuation's URL, as this would prevent the user from hitting the back button. This happens because the cookie is set globally, for the whole domain. Hitting the back button will not change the cookie's value to point to the right page. So clearly you need a way to encode the continuation's URL in the page itself, rather than assign it to a cookie. Now if you do this, on the server side you need a way to extract the continuation's id from the request, obtain the continuation and invoke it. Rather than imposing a fixed URL scheme, I now believe the task of identifying the continuation's id should be left to the sitemap. A sitemap admin could map continuations to different URLs, to fit the general look of the URL on that site. Something like this: <map:match pattern="continue/(.*)"> <map:call function=invoke-continuation"> <map:parameter name="id" value="{1}"/> </map:call> </map:match> "invoke-continuation" is a special function which takes a continuation id, determines the continuation, and invokes it, effectively restarting the processing. > Ovidiu said: > > > You can then mount each function at different URLs: > > > > http://foo.com/first/ > > Just checking - you'd intend this to be mapped automatically from the > function name? No, it's also based on the sitemap. Check-out the current sitemap in schecoon, to see how this is done: http://cvs.apache.org/viewcvs.cgi/xml-cocoon2/src/scratchpad/schecoon/we bapp/sitemap.xmap?rev=1.2&content-type=text/vnd.viewcvs-markup > Ovidiu said: > > > send-page("show-shopping-cart.xml"); > > operation = request.getParameter("operation"); > > if (operation == "continue-shopping") > > send-page("continue-shopping"); > > else if (operation == "buy") > > buy(); > > else if (operation == "update-quantities") > > update-quantities(); > > I realise this was just a first attempt to demonstrate a Javascript like > language, but the sort of code above is going to appear _all_ the time. > And it is loosely cohesive too, since presumably in > show-shopping-cart.xml there are magically-named fields corresponding to > the operations "continue-shopping". > > Surely it would be much nicer to have each page defined as a first-class > entity + operations _within_ your flow-language. Encourage the OO > style, e.g. this sort of thing > > Class customer { > IDType ID; > String name; > String address; > } > > class Cart { > customer c; > order_goods gs; > } > > //class page is predefined, included reflecting show method > > class Cart_page : page { > Cart c; > buy() { new Checkout_page(c).show() } > continue_shopping() { new Shopping_page(c).show() } > . > } > > With the continuation handling stuff in the predefined show() methods. > All the xml would be generated automagically. Code-generators could > also be written for various backend solutions. There are plenty of > object-models available out there for scheme. All you'd have to write > would be the transforming code. I'm sure this would be an option for us, programmers, but Web page designers would probably still want their HTML/XML pages. I believe the send-page(xml-filename, pipeline-name, data-dictionary) makes for a more separation between flow, logic and presentation. > Ovidiu said: > > > Also I don't like to express logic in XML, it's not what it was > > designed for. We need a programming language, so why use an XML syntax > > to express this? The attempts to use XML to implement a programming > > language are taking XML too far, where it wasn't designed to work. > > > > -- > > > > I think with the new model, there's no need for actions, redirects and > > other things that the sitemap currently has. They are no longer needed > > as you have full control over what's going on in your application at > > the program level. And you can control your application in a much > > better way than before. > > > > In the new model, the sitemap becomes a dispatcher to either a > > pipeline, or to a function in our language with implicit continuations > > (any good name for it?). > > All this is what I like best. It will let C2 return to what it's good > at. The poor old sitemap is groaning under the stress. And actions are > *@#$! Yep! > So what would be the first step? A flow-program generator for the > schecoon sitemap? Right now I have a simple XML sitemap implementation written entirely in Scheme. It allows me to specify: - matchers that contain simple pipelines, that contain either of these: - generator transformer* serializer - reader - call resource - call a Scheme function - resources: these are simple pipeline definitions, which have a name associated with them. The Scheme implementation reads an XML sitemap and translates it into Scheme code. The resources are translated to Scheme functions, so calling a resource is nothing else than calling a Scheme function (read very fast, possibly faster than today's compiled sitemap approach, though I didn't test it yet). You can declare Scheme functions to be called from the sitemap. These functions are defined in a special way, which allows the sitemap to pass named arguments, without having to be worried about their position as formal arguments of the Scheme function. The next step is to implement the mechanism for storing continuations, identifying them, and invoking them on request. This should be easy to do. Once this last step is done, you can start writing flow programs in Scheme! The last step is to write a translator from a more friendly language to Scheme. This is the hardest part, as I'm not sure what features this language needs to have. I'm trying to decide on this, and prototype a little bit with it. As a showcase for the new Cocoon architecture, I'm thinking to take the J2EE PetStore application and rewrite it with Cocoon's flow support. A colleague of mine is also working on replacing the EJB backend with a Web services implementation, so this should be a nice and round, example of the possibilities of Cocoon. Another line of action would be to investigate how this stuff and the TreeProcessor will fit together. My Scheme stuff is likely to not support some of the old stuff from the compiled sitemap, which Sylvain's TreeProcessor implementation supports. The easiest way right now is to have different subsitemaps running using different implementations. I haven't done any tests yet, but it should be possible to have a TreeProcessor sitemap implementation mount a Scheme sitemap implementation. This is suboptimal though, as one will not be able to take advantage of the old features together with the new ones, unless things are separated in different sitemaps. A better thing to do is to hookup the mechanism for calling Scheme functions in the TreeProcessor implementation directly, in which case the Scheme sitemap implementation becomes useless. We'll see as things evolve what's the best way to proceed. Regards, -- Ovidiu Predescu <[EMAIL PROTECTED]> http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff) --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED] --------------------------------------------------------------------- To unsubscribe, e-mail: [EMAIL PROTECTED] For additional commands, email: [EMAIL PROTECTED]
