Random notes from IRC about the architectural direction that session should go in..

17:01 < invinity> anybody know what the plan is for P::Session under Cat 5.8+? I'm using CookiedSession, but it doesn't play well 
                  with other plugins that $c->isa("C::P::Session"). I'd like to do a Moosified version of P::Session that defines 
                  roles for a generic Session interface and Flash, but I'm not sure where it stands with 5.8.
17:02 <@mst> I don't believe it should be roles
17:02 <@mst> I think a driver model like auth now uses is better
17:02 -!- sca [~sca@pc56421.bibliothek.uni-regensburg.de] has quit [Quit: Nettalk6 - www.ntalk.de]
17:02 < invinity> mst: ok, cool
17:03 < invinity> mst: is P::Auth currently Moosified?
17:03 <@mst> no, but that's not really relevant
17:03 <@mst> CookiedSession was the wrong approach; it was basically "acme decided integrating with the standard was hard so 
             didn't bother"
17:05 <@acme> i did spend a week trying to get the standard working
17:31 < nothingmuch> invinity: look at Session::Store::Delegate
17:38 < invinity> nothingmuch: are you recommending P::Session::S::Delegate as a way to use P::Session and write a Store delegate 
                  to use the Cookie?
17:38 < nothingmuch> yep
17:39 < nothingmuch> also see CGI::Cookjie::Splitter
17:39 < nothingmuch> and Crypt::Util
17:39 < purl> it has been said that Crypt::Util is much better
17:39 < nothingmuch> which you can use to tamper protect strings or data easily
17:41 < invinity> nothingmuch: ok, part of my thinking with using the Cookie is that there is then no need to generate a session 
                  id and maybe even skip some other facilities of P::Session, but I don't think this is very possible with the 
                  current P::Session unless some of its methods are overridden
17:42 < invinity> nothingmuch: and i'm not sure if that's very sane
17:42 < nothingmuch> corret
17:42 < nothingmuch> the current session system really sucks
17:43 < nothingmuch> but it shouldn't matter, you can let it just throw away the session ID
17:43 < nothingmuch> or make the whole session the session ID
17:43 < invinity> yeah
17:47 < invinity> i was thinking of some type of "layered" session system where the task of generating IDs could be delegated to 
                  the Store which would allow the Store to skip that step if it doesn't need it
17:47 <@mst> I occasionally wonder if session wouldn't be better just delegating to a Session model
17:48 < nothingmuch> if you want to rehaul the entire thing it should just use delegates
17:48 <@mst> which can then use ACCEPT_CONTEXT to set itself up however it requires
17:48 < nothingmuch> mst: that's pretty much Seession::Store::Delegate
17:48 < nothingmuch> but not as well integrated
17:48 <@mst> yes
17:48 < nothingmuch> definitely ++
17:49 < nothingmuch> this system has to move away from the inheritence model no matter how you look at it
17:49 < invinity> i still like the idea of a replacement for $c->isa("C::P::Session") that allows for a very basic session 
                  "interface" check
17:49 <@mst> invinity: post 5.80
17:49 < nothingmuch> that's trivial
17:49 <@mst> we need to get application/context split done
17:49 <@mst> then we go for roles for everything
17:50 < nothingmuch> compatibility can be provided later, but the core has to be redone