<div dir="ltr"><br><div class="gmail_extra"><br><br><div class="gmail_quote">On Sun, Sep 29, 2013 at 2:47 PM, Philippe Marschall <span dir="ltr"><<a href="mailto:philippe.marschall@gmail.com" target="_blank">philippe.marschall@gmail.com</a>></span> wrote:<br>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im">On Sat, Sep 28, 2013 at 8:34 PM, Julian Fitzell <<a href="mailto:jfitzell@gmail.com">jfitzell@gmail.com</a>> wrote:<br>
</div><div class="im">
> I hate that we do that, but if the child knows its key rather<br>
> than the parent, then everything you put in there needs to know a key.<br>
><br>
> Sessions don't really *need* to know their keys except when generating URLs<br>
> of course (or do they?) and that's a problem common to all request handlers.<br>
<br>
</div>Yes, however usually we don't have as many request handlers per<br>
dispatcher as we have sessions per application so #keyForValue: is<br>
less of an issue there. As for sessions specifically I can't think of<br>
a use case where we would like to have two different keys for the same<br>
session.<br>
<div class="im"><span style="color:rgb(34,34,34)"></span></div></blockquote><div><br></div><div>No, nor can I. I also don't think Applications should be holding onto any handlers other than Sessions in the session dictionary. So maybe it does make sense to optimize there. Maybe Application should just subclass RequestHandler directly.</div>
<blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex"><div class="im"><span style="color:rgb(34,34,34)"> </span><br></div></blockquote><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex">
<div class="im">
> As you know, the last change I was playing with was separating the<br>
> "key-based persistence" part of Session from the "application request<br>
> handling" part and one of the things I was struggling with there was how the<br>
> heck do the request handlers know how to refer to themselves. As I said, I<br>
> don't think this problem is unique to sessions, though.<br>
><br>
> Anyway, just a rambling email that can be summarized with: there are<br>
> certainly good arguments for sessions to know their key; I think there's a<br>
> tension there that still hasn't been perfectly resolved. Maybe it can't be?<br>
<br>
</div>We'll I guess it depends to which extent we accept the current<br>
limitations or want to build something more generic.</blockquote><div><br></div><div>I guess I'm always uncomfortable solving a problem in one place when I can see a more general form exists in other places. There's definitely something "not quite right" about how we hold handler keys and how we generate URLs. But Applications holding onto Sessions is definitely a special case and I don't think there's anything wrong with them being more tightly coupled since they always work together.</div>
<div><br></div><div>Julian</div></div></div></div>