[Catalyst-commits] r9180 - trunk/Catalyst-Plugin-Session

t0m at dev.catalyst.perl.org t0m at dev.catalyst.perl.org
Tue Feb 3 18:05:06 GMT 2009


Author: t0m
Date: 2009-02-03 18:05:06 +0000 (Tue, 03 Feb 2009)
New Revision: 9180

Added:
   trunk/Catalyst-Plugin-Session/IDEAS.txt
Log:
Add irc log of conversation about where ::Session should go, so next time this comes up I can link it in channel and we've got a starting point for discussion

Added: trunk/Catalyst-Plugin-Session/IDEAS.txt
===================================================================
--- trunk/Catalyst-Plugin-Session/IDEAS.txt	                        (rev 0)
+++ trunk/Catalyst-Plugin-Session/IDEAS.txt	2009-02-03 18:05:06 UTC (rev 9180)
@@ -0,0 +1,49 @@
+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 at 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
+




More information about the Catalyst-commits mailing list