Mailing-List: contact cocoon-dev-help@xml.apache.org; run by ezmlm
Precedence: bulk
Reply-To: cocoon-dev@xml.apache.org
Message-Id: <200202020029.g120Tmu18483@orion.rgv.hp.com>
From: Ovidiu Predescu <ovidiu@cup.hp.com>
To: Judson Lester <judson@irev2.com>
Cc: Allan Erskine <a.erskine@cs.ucl.ac.uk>, cocoon-dev@xml.apache.org
Subject: Re: first impressions on continuations idea 
In-Reply-To: Your message of "Fri, 01 Feb 2002 12:53:32 CST."
             <auto-000002580190@biggenerator.etool.com>
MIME-Version: 1.0
Content-Type: text/plain; charset=us-ascii
Date: Fri, 01 Feb 2002 16:29:48 -0800
Sender: ovidiu@orion.rgv.hp.com

Hi Judson,

On Fri, 1 Feb 2002 12:53:32 -0600, Judson Lester <judson@irev2.com> wrote:

> > > 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.
> >
> 
> I personally agree with Allan, that trying to encode a user in his URL is 
> problematic.  However, I don't see why it would be impossible to establish a 
> cookie backed session, and then store the coninuation tree in the session, 
> with a map of URLs to continuations.  This gives you the session-hijacking 
> protection established by Servlet session scopes, but allows you to also get 
> back-button-to-previous-continuation feature that Ovidiu has slowly brought 
> me to understand completely.  

Ah, I see your point. Allan and you propose a two level indirection
scheme to obtain the continuation. The first level is keyed by the
cookie, and points to the session object. The second level is keyed by
the URL and points to the continuation.

This would probably work fine if an URL has exactly one continuation
associated. However I'm afraid this may not be the case, an
application may use the same URL multiple times to do different
tasks.

Suppose we have this case:

History stack
    /a
    /b
    /c
    /a
    /d
=>  /a

Now the user hits the back button, so the history stack looks now like this:

    /a
    /b
=>  /c
    /a
    /d
    /a

Now all the /a URLs share the same continuation, thus if the user
clicks on the link to go to /a, he will go to the place in the
application corresponding to the last /a!

I don't see any way how this could work, other than POSTing additional
information. But this is equivalent to placing an identifier for the
continuation directly in the page, which renders useless the above two
level indirection scheme.

So either POSTing or encoding in the URL the continuation identifier
should do it.

Did I miss anything from your idea?

> > 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.
> >
> 
> Did you want to discuss at all your thinking in this regard?

I'd like to come up with a language in which I could have a syntax for
capturing the continuation, rather than having implicit special
functions that hide this fact. However this seems to be a difficult
task to achieve in a language with syntax, as opposed to s-expression
explicit languages like Lisp. I'd like to have continuations in the
core of the language, so that it's possible for programmers to write
their own "special functions", without having to go to the Scheme
layer underneath to do it.

I'm looking into JavaScript more closely right now, to get some ideas
on the syntax to use. JavaScript implements functions as first-class
objects, but it doesn't go as far as Scheme to have lexical closures
(nested functions) or macros.

I'm reading a lot of papers on this subject, but I feel I'm still not
close to a satisfactory solution.

Any ideas are appreciated as usual ;-)

Greetings,
-- 
Ovidiu Predescu <ovidiu@cup.hp.com>
http://www.geocities.com/SiliconValley/Monitor/7464/ (GNU, Emacs, other stuff)

---------------------------------------------------------------------
To unsubscribe, e-mail: cocoon-dev-unsubscribe@xml.apache.org
For additional commands, email: cocoon-dev-help@xml.apache.org