[Seaside] sessions and non-sessions
avi.bryant at gmail.com
Sat Feb 5 20:35:40 CET 2005
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
> 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.
More information about the Seaside