[Seaside] sessions and non-sessions

[Michal]

> The interesting value Seaside adds is in dealing with sessions, and
> anything that is explicitly sessionless/stateless should really be
> done with some other tool. The reason for that is that, at least as
> far as I've been able to figure out, this is an all-or-nothing
> choice per application: either you use sessions or you don't.

Really? I must be missing something - depending on what you mean exactly by the above - I see many examples that want both sessions and non-sessions.

Take something like smallblog as an example. It has two fairly different uses: displaying blogs for people to read, editing blogs for people who want to post. The two uses are basically in complementary distribution wrt sessions. The first use gains nothing from sessions and wants "the advantages of sessionless apps (like bookmarking and static indexing ...)". The second use on the other hand is wonderfully helped by the session mechanisms and doesn't care about bookmarking / indexing / etc. So at first sight, here we have a case that is not "an all-or-nothing choice per application", but rather "I want both, in different parts of the code".

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. I have tried solutions on both extremes in past projects: from the standard "everything is a session" - by far easier to code given the current framework - to the other extreme of "only editing is a session and everytime an object is edited it is rendered to static html served by apache" (unpleasant to code, more complicated underlyingly, but a more pleasant user experience). But they are both somewhat frustrating.

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.

Michal