IDEAS.txt

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