> 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.
Gahh - this is getting complicated! I didn't say that! I think we're
all coming from the same/different direction.
This is what I understand. An executing program looks like this:
---what happened then-----> !n! >-----what will happen next (cc)
-----
-^-
-^-
what's happening now
where "what will happen next" is labelled cc to stand for the "current
continuation" of that program.
Scheme is about the only language around that can obtain these cc's and
manipulate them as first class values, and Ovidiu's created the amazing
new schecoon project; hopefully easy manipulation of program
continuations can go a long way towards solving everyone's
web-app/flow-management woes.
So a web-app that involves a computation over many pages can be written
in the form of a normal program (in some familiar Java like syntax that
gets interpreted to Scheme in the background):
Page start_page = new Page("start.xml"); //note, could also
construct
//programmatically
Operation next_op = start_page.show().get_user_action();
next_op.apply();
...
class buy : Operation {
apply() { remove cart contents from database; fleece customer }
}
...
In the above example, you'd expect to wait between showing the start
page, and capturing the user's next action.
---blah Operation------> !show()! >-----get_user_action()
(cc) -----
-^-
-^-
what's happening now
In the background, this would be achieved by capturing the current
continuation (ie .get_user_action(); ...). This would be stored on the
server, and a continuation-ID representing it would be stored with the
client (in the URL, or encoded on the page in a hidden field). When the
client posts their request, the cont-ID is used to fish the continuation
out, and it continues to run on the server. This is MAGIC; we hardly
even have to _think_ about our application flow.
Now what is even better, and where I think we were getting confused is
that continuations can be used as a way to control what happens if a
user decides to spawn multiple browsers, and use their back button
willy-nilly.
Continuations can be used to respond to this situation in _whatever_ way
we'd like. All with minimal logic overhead.
Situation 1 - you want the user to be able to follow a single path
through your app
Just use plain continuations as described above. After running the
continuation, you could replace it with a different one under the same
ID, redirecting the user to a not-there-anymore page, should they have
used back or the likes.
Situation 2 - you really want the user to be navigating two ways through
your app in parallel (madness!)
Fish the continuation out, according to its ID. Clone it, and run the
clone. Place the original back under the same ID, in case the mad user
wants to run it under a different context (e.g. with different request
parameters)
Situtation 3 - you want to allow the user to navigate many ways through
the program, and you want to know what the *£@# is going on
Fish the continuation out, clone it, and run the clone with some
side-data (e.g. something resembling a mutex as in threaded
programming). Create a new continuation from the first one by adding
some corresponding side-data (another mutex say), and store this again
under the original ID.
Now two parallel threads can run through your web-app, but still be
under your _strict_ control! You can know exactly what's going on, if
you want to(!).
That really covers most cases, AFAIK.
All that needs settled is the following:
1) Where to store the continuation ID client-side. I think the only
logical choice is as a request-param, either in a hidden field, or in
the URL as a param (ie foo.com/buy?cont_id=4gf...). I take back what I
said about sessions. Continuations will be used in a slightly different
way, as we expect to be able to manage more with our continutations as
envisaged with sessions/cookies.
2) What language features to provide developers to express their
application flow. Ovidiu recommends a Java-like syntax, and I'd go with
this. I agree it would be good to provide them with a good abstraction
for the continuations, should they want to get their hands dirty. But
it would also be very nice to provide and encourage a way of describing
flow with anyone having to think about the continuations being used in
the background.
3) How the new schecoon features are to interact with the current
sitemap. I'd suggest letting the sitemap do what it's good at. I'd
suggest only ONE point of reference in the sitemap to a part of
application-flow that is to be managed by schecoon. And for schecoon to
manage all the URI's and parameters corresponding to actions. Otherwise
you end up duplicating concerns across both application flow, and the
sitemap.
So definitely no sitemap entries corresponding to actions that are
already dealt with by functions in the schecoon setup. These should be
automatically mapped onto URI's by name. The sitemap should really just
point to an application in a pipeline, and run all the corresponding
transformations/aggregations on the resulting data.
Does this sound OK/familiar to what others are thinking?
Allan
-----Original Message-----
From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]] On Behalf
Of Ovidiu Predescu
Sent: 02 February 2002 00:30
To: Judson Lester
Cc: Allan Erskine; [EMAIL PROTECTED]
Subject: Re: first impressions on continuations idea
Hi Judson,
On Fri, 1 Feb 2002 12:53:32 -0600, Judson Lester <[EMAIL PROTECTED]>
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 <[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]
