[Seaside] sessions and non-sessions

[Avi Bryant]

On Tue, 1 Feb 2005 20:25:40 +0100, Michal <miso.list at auf.net> wrote:

> Clearly, there is nothing particular to smallblog here. Anything that both displays and edits a data structre / database is an example of that, if it doesn't need to track the viewing. And that - at least in my world - is a very frequent pattern.

Ok, excellent point, and SmallBlog is a good example, because we
certainly struggled some with making it feel stateless enough for the
reading part.

> Whenever I'll find some time, I'm inclined to experiment with a kind of WAApplication that dispatches both to session objects and to objects that just render themselves (and have static, indexable urls, etc). I haven't had time to think that through and hack on it yet, but I'd be very interested in hearing how others see that division of labor.

What I find interesting about the approach I think you're suggesting
is that you're *not* doing what I usually think of as an advantage of
the stateless approach, which is giving "pretty" URLs - you're just
assigning unique ids to objects that will be in the image for a long
time, right?  This might allow for a smoother transition/integration
with Seaside, because the way request handling and response generation
works could potentially be very similar, you'd just be choosing at
each point whether to register a short-lived callback that knew lots
of local information but wasn't expected to stick around forever (eg,
a typical Seaside action callback), or a longer-lived object that
necessarily carried with it much less state.  That suggests that it
might even be possible to rig specific components to work in either a
stateless/sessionless or session-ful context.  Anyway, I'm very
interested to see how this turns out.

Avi