Re: [cgiapp] [OT] CGI::Session is good, but we can do better (a new project is born?)

["Jason A. Crome" <suppressed>]

I, for one, completely agree.  I like the interface of CGI::Session, but 
the implementation and level of support leave much to be desired.

I'd be happy to give whatever time and assistance I can to make this 
happen.  I started a thread or two on this at some point in the past, 
but kind of let it slide when the betas of C::S 4.0 came rolling out.  
As I'm not much more impressed by C::S 4, I wouldn't mind reviving those 
old ideas. 

One thing I'm not sure about is dumping the whole session object into 
one field.  At times, I definitely find it useful to have a column for 
each piece of data that I wish to keep in the session.  Other times, 
honestly, I find it really helpful to dump all sorts of things into the 
session without having to think much about it.  I think completely 
removing this ability will really alienate some potential C::S users.  
There any way we can do allow a user to choose which method they 
prefer?  Some sort of argument we can pass when we create() the new session?

C::S has been a good module, but I agree, we should replace it with 
something better and more sane (hell, just expiring sessions in the way 
you describe makes this a worthy effort!).  Again, I'd be happy to offer 
whatever time and assistance I can to make it happen. 

Look forward to more discussion here, and if so inclined, would be happy 
to brainstorm/hack at YAPC ;)

Jason

Mark Stosberg wrote:

> I've had a number frustrations with CGI::Session and am considering
> creating yet another alternative. What I have liked about CGI::Session
> is the general interface. While I'm at home writing custom SQL, I liked
> having the session code wrapped up in a neat little object, fairly
> separate from the rest of the database logic. 
>
> However, it has an overly complex structure that has made it hard to 
> debug session related problems. It shouldn't be required to have a
> driver for every database backend when it's mostly doing simple
> operations on one table. It's unhelpful that it dumps the whole session
> object into one database column. This limits the usefulness of access to
> the data almost any other way but through the session interface. 
>
> I have a vision for a highly compatible interface with these improvements:
>
> - A lightweight code base. The code will focus on session-specific
>   logic. The concepts of Serializers will be banished.
>
> - The storage focus will database-centric, not file-centric. Use
>   DBD::SQLite if you don't want/have a real DB. This will make it more
>   natural and uniform to implement solutions to expire all sessions
>   based on a criteria, and implement other logic related to sets of
>   sessions. 
>
> - Support custom ID generators via callbacks. I like the idea of custom
>   ID generators, but the current API requires creating your own package
>   for this. I would additionally support a callback interface for
>   quickies:
>      id => sub { int rand(100) }, # a bad example? 
>
> Class::DBI seems like a natural foundation for this. Although I haven't
> ( yet ) implemented an application with Class::DBI, this might be it. 
> I've made a little chart of the key methods of CGI::Session, and how
> they might be implemented in a Class::DBI-derived application. 
>
> You can see that several methods will come for "free" just be virtue
> of having the database columns named the same way. A few others
> are just thin wrappers. That leaves only new() and expire() with much
> customized logic, some of which can be lifted from CGI::Session. 
>
> CGI::Session  | DBI::Session  ( not firm about a name choice yet )
> ----------------------------------------------------------------------
> new()         | Needs to copy simple logic from _init to decide whether to
>               | open an existing session or create a new one.
>               | Call create() to create a new
>               | one. Also handles ID generation, which can be customized
>               | with a callback.
>
> param()       | Thin wrapper: param( year => 1981 ) becomes year('1981');
> clear()       | Thin wrapper to update to set specific fields to undef
> close()       | Thin wrapper: calls update()
> expire()      | Similar: use expire(), but pass in DB format times.
>                  (Compatibility for CGI.pm cookie style
>                   could be ripped from CGI::Session).
>
> delete()      | free: delete()
> id            | free: id()
> atime         | free: atime()
> ctime         | free: ctime()
> remote_addr   | free: remote_addr()
> error         | Not needed, but could be emulated with eval() and suppressed
> dump          | Not needed, but could be emulated easily
>
> This weekend I have about 10 hours of laptop-time in the car, maybe I'll
> try to hack up a first draft of this. 
>
> Are others interested in helping? At this point it seems more attractive
> to me than updating my driver and code to work with CGI::Session 4.x.
>
>    Mark
>
>  


---------------------------------------------------------------------
Web Archive:  http://www.mail-archive.com/suppressed/
             http://marc.theaimsgroup.com/?l=cgiapp&r=1&w=2
To unsubscribe, e-mail: suppressed
For additional commands, e-mail: suppressed