[Seaside-dev] Sessions should know their keys

[Julian Fitzell]

Yes, I've had the same thought before and I've struggled back and forth
with it a few times. At some level, I feel like request handlers should be
able to receive requests via multiple paths (two different server adaptors
with different encodings, for example), and therefore we should generally
be relying on a context-based definition of parent (i.e. what's the
previous handler in the handler's chain), rather than a single
container-based parent. And that's part of the reason that request handlers
don't know their keys, I think. Also, don't we still store instances of
other classes in the Application? I hate that we do that, but if the child
knows its key rather than the parent, then everything you put in there
needs to know a key.

Sessions don't really *need* to know their keys except when generating URLs
of course (or do they?) and that's a problem common to all request
handlers. As you know, the last change I was playing with was separating
the "key-based persistence" part of Session from the "application request
handling" part and one of the things I was struggling with there *was* how
the heck do the request handlers know how to refer to themselves. As I
said, I don't think this problem is unique to sessions, though.

Anyway, just a rambling email that can be summarized with: there are
certainly good arguments for sessions to know their key; I think there's a
tension there that still hasn't been perfectly resolved. Maybe it can't be?

Julian


On Fri, Sep 20, 2013 at 12:06 PM, Philippe Marschall <
philippe.marschall at gmail.com> wrote:

> Hi
>
> Don't worry, this is not something I'm proposing for 3.1.
>
> I'm currently looking at overhauling the cache for sessions and
> continuations (again). Something I stumbled upon is that a cache has
> to do both key -> value and value -> key mappings. This has several
> downsides.
> First it makes the cache implementation more complicated, effectively
> you have to use two dictionaries instead of only one. This also adds
> to the memory consumption.
> Second it actually does not scale very well on Squeak/Pharo because we
> use #hash of Object which is AFAIK limited to 4096 distinct values.
> Caches bigger than this will start seeing collisions and linear
> complexity. This isn't as bad anymore as in the old times, the values
> will be spread better over the table so we'll have 4096 collisions
> instead of one huge one. We could in theory generate a random number
> and use this as #hash but then we could just as well use this as a
> session key.
>
> I can see two possible explanations why sessions currently don't know
> their keys.
> First in Seaside 3.0 request handlers don't know their name anymore.
> This was AFAIK done to simplify the registration, however since a
> request handler must know its parent it's questionable whether this is
> still true.
> Second the session key is actually generated when the session is
> stored in the cache.
>
> What do you think?
>
> Cheers
> Philippe
> _______________________________________________
> seaside-dev mailing list
> seaside-dev at lists.squeakfoundation.org
> http://lists.squeakfoundation.org/mailman/listinfo/seaside-dev
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.squeakfoundation.org/pipermail/seaside-dev/attachments/20130928/f9971c93/attachment.htm