[Seaside-dev] Re: Making ‘_k’ and ‘_s’ optional: A Seaside Heresy?

[Dale Henrichs]

Julian Fitzell wrote:

>In reference to
>http://gemstonesoup.wordpress.com/2008/08/07/making-_k-and-_s-optional-a-seaside-heresy/
>
>Dale,
>
>Heresy schmeresy!
>
>Amazingly, I have been thinking about this myself over the past few
>weeks. I have been refactoring the component hierarchy to give us a
>superclass we can actually use that does not support call/answer
>(sometimes you don't need it) and does not require a session unless it
>needs to persist state. I've also been doing configuration refactoring
>and that has had me thinking a lot of dependencies between various
>layers of the request handler hierarchy. And I was starting to ponder
>whether there wouldn't be some way to have an application use RESTful
>urls until a callback was triggered to require a session.
>  
>
Very interesting this is right in the area I was aiming at. If your 
RESTful session work in the configuration refactoring packages? If so, I 
could load it up and start playing with it.

>Now my thinking was more along the lines of having no session at all,
>rather than creating a new default session for each request. But I
>haven't really thought through as far as an implementation yet and
>doing it that way might well require too much manual effort on the
>part of the developer, so creating a new session each time may be
>unavoidable.
>  
>
Before the aha moment for 'eliminating _s', I was imagining that it 
would be possible to have a singleton read only session that would 
handle the load for 'sessionless' request handling.

When I approached the problem from the 'eliminate _s' angle, it was 
natural (read easy to implement) to create a default session just like 
you would whenever the '_s' was missing and then lazily save the session 
if you ended up needing a session in the URL.

I think avoiding new session creation would be a good thing, but 
creating a session and droppping it on the floor is better than hanging 
onto it when it isn't needed:)

>It seems like you may be going further and advocating dropping the _k
>even once a persistent session has been created?
>  
>
Yeah, I wasn't trying to go full bore RESTful (where any session state 
at all is taboo), so I thought there'd be a use case where you want to 
propogate server session state with an '_s', but if the page that was 
being rendered happened to be RESTful, then there wouldn't be a need to 
save a continuation. I used a WANavigationContinuation for handling 
requests with no '_k' which is the moral equivalent of a defaultSession.

>Also, we need to remember that _k isn't only needed for callbacks, but
>also for backtracked UI state like whether a tree is expanded and so
>on. We'd be losing out on that possibility as well. Again, I was sort
>of picturing the developer creating a RESTful browsing interface
>without any state, but of course you could presumably just detect if
>any of the components returns anything in #states and start tracking
>_s and _k at that point.
>  
>
This is what I was aiming for ... if you don't need a continuation, 
don't just save one blindly.

>I haven't looked at your code yet but may try to do so today.  In
>general, though, I definitely think the idea is interesting and the
>goal worth pursuing if we can do it cleanly and without it feeling
>hacked in.
>
Agreed.

Being able to do a RESTful application using Seaside (that really 
doesn't save state) goes a long way towards what I was aiming at, but I  
imagined that a 95% RESTful Seaside application with 5% taking full 
advantage of session state would be a powerful weapon and to do that I 
think you wander into the optional _k, _s territory.

Dale