[Catalyst-dev] Another Session discussion

Matt Pitts mpitts at a3its.com
Wed Feb 4 18:21:16 GMT 2009


> -----Original Message-----
> From: Tomas Doran [mailto:bobtfish at bobtfish.net]
> Sent: Wednesday, February 04, 2009 12:28 PM
> To: Development of the elegant MVC web framework
> Subject: Re: [Catalyst-dev] Another Session discussion
> 
> 
> On 4 Feb 2009, at 16:55, Matt Pitts wrote:
> 
> > I started hacking on a Moose-based Session plugin that uses Roles
and
> > delegation to a specified $c->model for storage. My main
> justification
> > for this work is to just get my own gears turning, so these are just
> > ideas, and I'd be happy to scrap it there's already something
> started.
> 
> There isn't anything started other than the vague ideas discussed the
> other day on irc.
> 
> If you have _any_ code at all, please grab a commit bit and get a
> branch of Plugin::Session (even if you throw away all the code in it
> and start again) so that the code is public - as quite a lot of
> people prefer to read code than to read text, and it'll also be nice
> to capture the entire development from beginning to end in revision
> history.

Agreed. What do I need to provide - htpasswd line?

> > A Roles distribution:
> 
> Are you thinking of this as actually a different dist, or as part of
> the session plugin? As Session::Store::XXXX will require
> Plugin::Session, so I don't see an issue bundling it in the main
> session dist.

Yes, that way anybody that wants to implement the Roles can do so
without having the whole P::Session dist.

> >
> >   Catalyst::Role::Session
> 
> <snip>
> 
> >   Catalyst::Role::Session::Flash
> >     - the basic methods necessary for flash functionality
> >     - interface
> >         requires 'flash';
> >         requires 'clear_flash';
> >         requires 'keep_flash';
> 
> Flash is a _bad idea_ as its not tab safe, so I'd only be supporting
> flash for backwards compatibility - I don't think there is any value
> to providing a new interface on ways to fail ;)

But Flash *could* be tab safe if the storage backend is tab safe, i.e.
HTML 5 "Structured client-side storage". Although, I don't claim to be
an expert so maybe I'm just talking out my ass. I really like the flash
functionality, though.

> >   Catalyst::Role::Session::Store
> >     - the basic methods necessary to implement a storage backend
> 
> <snip>
> 
> > The Main P::Session distribution:
> >
> >   Catalyst::Plugin::Session
> >     - consumes Catalyst::Role::Session
> >     - gets $self->_session_model from
> > $c->model($self->_session_model_class)
> >     - ensures that
> > $self->_session_model->has_role('Catalyst::Role::Session::Store')
> >     - delegates many functions to $self->_session_model
> 
> It would be nice to be able to use _any model_ at all for session
> storage, even one which hadn't been specifically 'sessionified' (I'm
> thinking specifically Catalyst::Model::Adaptor type models etc).
> 
> However there is nothing to stop you having a way to apply the role
> (which is just checking requirements really) to an arbitrary model...
> Worth thinking about anyway..

Yeah, I was actually wondering about that myself. I think it could be a
combination of both, but because of the Roles and the fact that
P::Session would already delegate much of the functionality to the
model, I would think it easier to write a C::M::Session::SomeCustomStore
that consumes C::R::Session::Store rather than a C::Model::Adapter based
model. As always, though, I'm sure someone would have a situation where
they'd want to.

> >   Catalyst::Model::Session::Cookie
> >     - consumes Catalyst::Role::Session::Store
> >
> >   Catalyst::Model::Session::DBIC
> >     - consumes Catalyst::Role::Session::Store
> >
> >   Catalyst::Model::Session::ImaginarySomething
> >     - consumes Catalyst::Role::Session::Store
> 
> How do things which don't have a store (such as, for example,
> something like Catalyst::Plugin::CookiedSession) fit into this scheme?

I'm not really thinking of an all-in-one case, but for C::P::CP I see
one of two ways:

 1. Catalyt::Model::Session::Cookie would deprecate it because it would
provide the same functionality under the new P::Session system

 2. CookiedSession could be refactored to consume
'Catalyst::Role::Session'; thereby providing a lightweight session
implementer that skips all the unnecessary model(ing). This goes back to
having C::Roles::Session as a separate distribution. One big issue here,
of course, is that existing plugins (Authentication is the big one) that
$c->isa('C::P::Session') will still not work with CookiedSession.


> > And that's about as far as I got, I thought I'd get opinions before
> > more
> > model starts coming about of my head. BTW, none of this actually
> works
> > yet, it's just conceptualize code.
> 
> Good call.
> 
> Maybe worth taking a round of feedback and then writing 'the plan' up
> in some text format in subversion so that anyone interested can check
> back on (and again, we have versioned history with comments as the
> plan evolves in the face of trying to actually implement it).

Agreed.
 
> > Oh, and I'm not even thinking about
> > compat right now.
> 
> Totally fair. Plan the new thing, get a prototype up to prove the
> 'plan' works, _then_ start thinking about how compat fits into the
> picture before everything is finalised..
> 
> Good stuff, and well volunteered - its nice to see session getting
> the redesign it needs / deserves.

Thanks!

v/r
-matt pitts



More information about the Catalyst-dev mailing list