> 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
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, email: [EMAIL PROTECTED]
