Sylvain Wallez wrote: > Torsten Curdt wrote: > >> Gang, >> >> there are a few things regarding the current flow machinery that >> are bugging me for quite a while now. In order to support flow >> serialization they need to be addressed. >> >> 1. Class vs Interface >> >> The WebContinuation is currently a class. IMO it makes much more >> sense to turn it into an interface an have the individual "FlowEngine" >> implementation act as a factory. That way javaflow could create >> WebContinuations that implement Serializable. > > > +1. >
+1 >> 2. Naming >> >> The name JavaInterpreter just misses the point. I would like to >> rename the "Interpreter" interface to something like "FlowEngine". >> Other suggestions are welcome. > > > +1 as well. I even proposed it 2 years ago [1] ;-) > +1, I remember :-) and find that the old doc (at new URL: http://wiki.apache.org/cocoon/GeneralizedFlow, ever so unreadable as back then) still holds some ideas worth considering, no? for one: the possibility to have more then one 'flowEngine' as you call it available inside one sitemap would be neat (and there were some more related re-naming suggestions for the sitemap syntax as well IIRC, maybe the future of a 2.2 release offers us the fork to concider some of that as well?) >> 3. Continuation Management >> >> When it comes down to serialization of flow there are 2 aspects. >> One is flow persistence and the other one is flow replication >> across machines. >> >> In order support flow persistence we would need the make the >> ContinuationManager save and reload serializable continuations. >> ...which is not big deal. Unfortunately replication is a slightly >> different subject. >> >> The distributed ContinuationManagers would need to synchronize >> the continuation trees across the network or at least find a way >> to direct to the appropriate server that holds the continuation. >> TBH ...I am not eager to re-invent the wheel here. In fact this >> whole machinery is already in place for sessions. Why not re-use it? >> In fact I don't really see a big point of having web continuations >> without sessions anyway. > > > +1 again. There aren't many real use cases where continuations span > several sessions. And being tied to session may be one of the > constraints/requirements to use clustered continuations. > I was glad enough to hear Torsten make his point on this IRL during drink/reception of this year's gettogether... >From a pure web/REST/temp resource POV I still like the idea of having dynamic URI's that can be shared between end users (thus regardless of their session) is kinda cool (think chatrooms/operators assisting in 'your' flow), but I think this kind of use could also be solved by smart redirects and some application level 'resource' management (probably be even safer then just having it de facto available) >> Assuming the continuations are stored inside the session, storing >> and restoring the sessions would take care of the persistence. >> Directing to the server with the right session also assures to >> get to the right cocoon instance running the right ContinuationManager. > And this nice explanation shows IMHO enough pragmatic bonusses... so +1 > > Yup. This is required also for load balancing. > >> Flow replication itself should then also be solved by session >> replication without any further effort. The only open question >> is the continuation expiry mechanism. It might be good enough to >> just run the expiry on every machine ...I am wondering how that >> might affect the replication though. > > > Looks like HttpSessionActivationListener can by our friend here, as it > allows session attributes to be notified when a session is passivated > and activated. > > Sylvain > > [1] http://marc.theaimsgroup.com/?l=xml-cocoon-dev&m=105732879827785&w=2 > -marc= -- Marc Portier http://outerthought.org/ Outerthought - Open Source, Java & XML Competence Support Center Read my weblog at http://blogs.cocoondev.org/mpo/ [EMAIL PROTECTED] [EMAIL PROTECTED]
