Torsten Curdt <[EMAIL PROTECTED]> writes:
>
>
> >>Hm... I cannot see how this would help. Continuations have
> >>there "stack" on the server side.
> >
> >
> > In general you're right it's not useful, you'd only be able
> to support
> > this with a back button on the page that told the server to pop the
> > stack. You wouldn't have browser back button support.
>
> I still don't see the gain...
>
> You basically have a tree of continuations on the server
> side. You don't have to "pop the stack" to show a particular leave.
>
Right, I should have made it clearer, even for our case where we don't
have a tree, I don't think this is worth doing...
> <snip/>
>
> > The issue is, in general, you want to associate a
> continuation with a
> > particular user and a particular page. As you point out, using a
> > single cookie doesn't work for the general case since you loose the
> > per page association.
>
> *nod*
>
> > However, a somewhat more general solution is to exploit
> cookie paths
> > to allow one cookie per page.
>
> ok
>
> > To do this you have to have
> > a unique path to each page.
>
> ok
>
> > The cookie rules are that you can look down
> > the path but you can't place a cookie at a place higher up the path
> > than the page. IOW, sever/x/x.html can have a cookie a
> path "x" or
> > at "/" but not at "x/y". So, you basically hack Cocoon to add a
> > redundant piece of path information to each page request
> that you then
> > factor back out in the site map.
>
> So if IIUC you then can store a continuationid per page.
>
> But that's not enough: you can have n continuationids per
> page! Maybe not much likely to happen very often - but not
> totally far out.
Yes, I can see that for some applications this might be useful. You
could get even more hacky, creating a stack of paths: x1, x2, x3, if
you're in a position to manage the calling URL correctly. However, for
us a page is a page is a page and we do not need separate state tracking
for multiple instances of them.
>
> > This works, I tested it yesterday, but I've since
>
> Did you try when you duplicate you browser window?
No, but I don't think it should be an issue, in memory cookies are
cloned at least for IE, but I've already trashed the code to work on the
new solution.
> > thought of a better solution which I'll post later today
> once I get a
> > chance to test it. (The general problem is that not all sites can
> > allow the page paths to be hacked in the manner I describe...)
>
> Eager to see what you bring up here :-)
>
> >>Well, as you say: it's a fact ;)
> >>...nothing much you can do about it
> >>
> >
> >
> > I think there is :-) look for a post with a title something like
> > "Continuations break caching - possible solution" later today...
>
> Did I miss it? Or am I still waiting :-)
You're still waiting... Basically as Sylvain suggests to Vadim in
another thread I'm implementing a ContinuationsManager that manages the
continuations in sessions. This does, as Sylvain hints, also solve the
problems of blowing away the continuations. I'm down to one issue:
In the sitemap, when calling an input module it would be nice if I could
pass a sitemap parameter to the module, IE:
<map:call continuation="{continuations-manager:{2}}"/>
I can work around this, but if this was supported directly the code
would be trivial (and I think it is still pretty close to trivial).
>
> > The
> > solution still requires session management, but it's more
> general and
> > easier to implement than what I've been playing with so far.
>
> Are we talking about server side or client side caching?
>
> Of course you *could* have each page cached. But 80% of
> the user actions would create a new page and place it
> into the cache because the key of the page has to include
> the continuationid. Otherwise external entities like
> flow variables would not
> correctly be reflected.
Both. In our system, as I've written before, all pages are forms and
can potentially be posted back to the server. However, 90% of the time
the user simply brings the data up and then does a GET on another page.
We can have 100's of instances of the same page being viewed at the same
time and I want to generate them all from the same Cocoon cache.
For flow to work the Cocoon cache key does not have to be unique per
page, the continuation has to be uniquely determined for a given page.
Two different things.... The only time you can't separate the two might
be if you really need to support multiple instances of the same page on
new instances of the browser window. There may be a way around that but
in our case I don't think its something we have to worry about.
> I really doubt a fully cachable pipeline is possible
> or does make sense in that context.
>
There are definitely trade offs to be made here. We have a little
better control over the situation than some people might since we
running an Intranet application where we can simply say, sorry, X is not
support (where X might be cloning an instance of a browser in this
case).
