Commit | Line | Data |
c5af59b5 |
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 | |