Sessions in D2 (was Before Hook hit multiple times).
On Thu, Jan 3, 2013 at 11:19 AM, Alexis Sukrieh <sukria@sukria.net> wrote:
I don't get it. Do you have something that works (or is supported) in Dancer 1 regarding session that is not in Dancer 2? If so, please enlight that, and I'd be very happy to fix it.
Look at the configuration values of Dancer::Session::Abstract. Are all supported in D2? Hint: ack for "session_name" in the D2 source tree, then ack for "dancer\.session". Sessions happened to be the very first thing I was curious about in D2, given bugs I was finding in D1. Then I looked and found a big oversight like session configuration apparently unimplemented. If I find that in the first place I look, should I expect similar oversights elsewhere? Do I need to grok the entire architecture and do a code review to be sure? Maybe I was (un)lucky and found the one place that still has issues, but it's that kind of thing that makes me uncomfortable switching. Did I do a code review of D1? No. But then I expect that a large number of people using it for a few years have found the issues already. (Part of why I came to use Dancer is that it has already been well-established.) On the surface, D2 looks like D1, but it's such a re-write that I don't want to be a super-early-adopter and certainly not until the unimplemented sections I did find are fixed. David -- David Golden <xdg@xdg.me> Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdg
Hello David, thanks for your response, 2013/1/3 David Golden <xdg@xdg.me>
On Thu, Jan 3, 2013 at 11:19 AM, Alexis Sukrieh <sukria@sukria.net> wrote:
I don't get it. Do you have something that works (or is supported) in
Dancer
1 regarding session that is not in Dancer 2? If so, please enlight that, and I'd be very happy to fix it.
Look at the configuration values of Dancer::Session::Abstract. Are all supported in D2?
Hint: ack for "session_name" in the D2 source tree, then ack for "dancer\.session".
Oh yes, you're right, I'll focus on this one as soon as I have time to go back to the code (hopefully this weekend).
Sessions happened to be the very first thing I was curious about in D2, given bugs I was finding in D1. Then I looked and found a big oversight like session configuration apparently unimplemented.
And I can tell you that the way sessions are handled in D2 are WAY better than in D1, exactly because of the experience I had with D1 bugs. I did a complete article in the advent calendar to stress how better it is now: http://advent.perldancer.org/2012/5 I understand your point, you spotted one thing that I forgot, the configuration bits, it's being handled soon. That's my next todo item for D2. I've assigned the issue to myself. If I find that in the first place I look, should I expect similar
oversights elsewhere?
I don't think so, although we should be honnest, D2 is younger than D1, of course, and yes, you're right, new software is less stable than old software. But my main point was that trying, or experimenting a D2 migration helps *a lot* D2 to move forward. See all the discussion that rose thanks to Celogeek's migraiton. I was just saying that it could be a very good opportunity for you to contribute and help us make D2 more stable, if you want to.
Do I need to grok the entire architecture and do a code review to be sure? Maybe I was (un)lucky and found the one place that still has issues, but it's that kind of thing that makes me uncomfortable switching.
I don't think you should do a code-review, although I'd be very happy to have even more eyes on the code, as always. I think D2 is ready now for real-life tests, that's why I said that. Of course, that means beta-testing the monster, which requires some spare time and goodwill, of course ;)
Did I do a code review of D1? No. But then I expect that a large number of people using it for a few years have found the issues already. (Part of why I came to use Dancer is that it has already been well-established.) On the surface, D2 looks like D1, but it's such a re-write that I don't want to be a super-early-adopter and certainly not until the unimplemented sections I did find are fixed.
I see your point of view, no problem ;) Stay tuned, then.
Maybe you want to check that out: https://github.com/PerlDancer/Dancer2/commit/940829d2b70c33ea401d5967c8f3d83... ;-)
On Fri, Jan 4, 2013 at 11:16 AM, Alexis Sukrieh <sukria@sukria.net> wrote:
Maybe you want to check that out: https://github.com/PerlDancer/Dancer2/commit/940829d2b70c33ea401d5967c8f3d83...
IMO, the 'sessIon_dir' option shouldn't be in the core config role. That's specific to a filestore-based session factory and should either have a default provided there or should simply require it in the config options. Dancer::Core::Session still does not support setting the domain as Dancer::Session::Abstract did. David -- David Golden <xdg@xdg.me> Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdg
On Fri, Jan 4, 2013 at 11:16 AM, Alexis Sukrieh <sukria@sukria.net> wrote:
Maybe you want to check that out: https://github.com/PerlDancer/Dancer2/commit/940829d2b70c33ea401d5967c8f3d83...
Also, this seems really redundant: session: YAML engines: session: YAML: session_config: cookie_name: 'session.foo.dancer' expires: 86400 Why does YAML need to be specified twice? David -- David Golden <xdg@xdg.me> Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdg
Because you can have many engines defined. Le 4 janv. 2013 18:56, "David Golden" <xdg@xdg.me> a écrit :
On Fri, Jan 4, 2013 at 11:16 AM, Alexis Sukrieh <sukria@sukria.net> wrote:
Maybe you want to check that out:
https://github.com/PerlDancer/Dancer2/commit/940829d2b70c33ea401d5967c8f3d83...
Also, this seems really redundant:
session: YAML engines: session: YAML: session_config: cookie_name: 'session.foo.dancer' expires: 86400
Why does YAML need to be specified twice?
David
-- David Golden <xdg@xdg.me> Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdg _______________________________________________ dancer-users mailing list dancer-users@dancer.pm http://lists.preshweb.co.uk/mailman/listinfo/dancer-users
On Fri, Jan 4, 2013 at 2:27 PM, Alexis Sukrieh <sukria@sukria.net> wrote:
Because you can have many engines defined.
Can you have many engines of a *type* defined? Looking at Core::Role::Config, it doesn't look like it. E.g. "session: YAML" goes and looks in "engines: session: YAML: ... ". Even if you defined multiple things under engines, nothing I can see would instantiate them or give access to them. Consider: session: YAML engines: session: YAML: session_config: cookie_name: 'session.yaml.dancer' expires: 86400 session: Sereal: session_config: cookie_name: 'session.sereal.dancer' expires: 86400 The engine() sub in Dancer::Core::App is just a wrapper around the config hash, so engine("session") is actually grabbing the top level session key (which has been inflated from "YAML" into an object). It doesn't grab something under engines. Which also means that engines("random_config_setting") works and has nothing to do with engines, which seems poor as well. It would seem to make more sense to me to inflate everything under engines (perhaps lazily), and have engines() return those, and let the top-level "session" key define the default engine used to set the 'session' in the request context object (and thus available via the DSL). Then you could do: hook 'begin' => sub { var alt_session => engine( session => "Sereal" )->retrieve; }; get "/" => sub { session Foo => "Bar"; # stored in YAML session alt_session Foo => "Baz"; #stored in Sereal session }; Admittedly, it's a bit complicated for sessions, since you need to flush and set cookies at the end of the request. (It woudn't be terribly hard to do some accounting of them.) But what I describe above generalizes to other engine types as well. On the other hand, if multiple engines aren't desired, then you could could eliminate the top-level key and just define everything under engines: # session: YAML # unnecessary # simple engines: session: YAML # with config engines: session: # with config class: YAML session_config: cookie_name: 'session.yaml.dancer' expires: 86400 session_dir: /tmp/dancer-session (If value is scalar, use with default config; if hash, get class key and pass rest to constructor.) Or, avoid the whole 'engines' config abstraction: # simple session: YAML # with config session: class: YAML session_config: cookie_name: 'session.yaml.dancer' expires: 86400 session_dir: /tmp/dancer-session You're inflating off the top-level key anyway, so all "engines" is doing is giving you a (redundant) place to park config data. David -- David Golden <xdg@xdg.me> Take back your inbox! → http://www.bunchmail.com/ Twitter/IRC: @xdg
participants (2)
-
Alexis Sukrieh -
David Golden