Mailing List Archive: Another Session discussion

Another Session discussion

Feb 4, 2009, 8:55 AM

Post #1 of 3 (2298 views)

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.
Here's what I've got so far...

A Roles distribution:

Catalyst::Role::Session
- the basic methods necessary for other stuff to use session
mechanisms ($c->has_role('Catalyst::Role::Session'))
- interface:
requires 'session';
requires 'sessionid';
requires 'session_is_valid';
requires 'delete_session';
requires 'delete_session_reason';
requires 'session_expire_key';
requires 'delete_expired_sessions';

Catalyst::Role::Session::Flash
- the basic methods necessary for flash functionality
- interface
requires 'flash';
requires 'clear_flash';
requires 'keep_flash';

Catalyst::Role::Session::Store
- the basic methods necessary to implement a storage backend
- interface
requires 'get_session_data';
requires 'set_session_data';
requires 'delete_session_data';
requires 'delete_expired_sessions';
requires 'generate_session_id';
requires 'session_is_valid';

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

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

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. Oh, and I'm not even thinking about
compat right now.

v/r

-mattpitts (invinity)

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

Re: Another Session discussion [ In reply to ]

bobtfish at bobtfish

Feb 4, 2009, 9:27 AM

Post #2 of 3 (2196 views)

Permalink

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.

> 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.

>
> 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 ;)

> 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..

> 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?

> 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).

> 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.

Cheers
t0m

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev

RE: Another Session discussion [ In reply to ]

mpitts at a3its

Feb 4, 2009, 10:21 AM

Post #3 of 3 (2170 views)

Permalink

> -----Original Message-----
> From: Tomas Doran [mailto:bobtfish@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

_______________________________________________
Catalyst-dev mailing list
Catalyst-dev@lists.scsys.co.uk
http://lists.scsys.co.uk/cgi-bin/mailman/listinfo/catalyst-dev