Re: [Cgi-session-user] Progress with CGI::Session::Serialize::yaml

[Mark S. <ma...@su...>]

On Sat, Feb 25, 2006 at 01:52:20PM -0800, Tyler MacDonald wrote:
> 
> 	OK, so being that all of the drivers have the exact same interface,
> and they're at least forwards-compatible (YAML can read JSON), I'd suggest
> that we have one serializer provide all of them. With the current API this
> equates to something like:
> 
> 	my $session = CGI::Session->new(undef, "s=yaml");
> 	$session->_serializer->use('JSON::Syck');
> 
> 	or
> 
> 	local $CGI::Session::Serializer::yaml::SERIALIZE_WITH = "JSON::Syck";
> 	my $session = new CGI::Session;
> 
> 	Do you think this is a good idea? Or should we have separate modules
> for YAML and JSON?

I think we should have seperate modules. Perhaps they will evolve
differently. The concept of serialization drivers is that each one is
providing a different serializing method. For one serialization driver
to serialize two different ways is a little confusion. 

But for reference, the contortions above shouldn't be necessary anyway.
There way a to pass arguments on through to the serializer through
new().  Here's the related docs:

 "If called with three arguments, first two will be treated as in the previous
  example, and third argument will be \%dsn_args, which will be passed to $dsn
  components (namely, driver, serializer and id generators) for initialization
  purposes. Since all the $dsn components must initialize to some default value,
  this third argument should not be required for most drivers to operate
  properly."

I believe a related convention here is to make keys in this hashref
unique by using a unique prefix, such as "pg_" for the PostgreSQL
driver, etc. 

> >  - adjust the tests to match the limitations of each.
> 
> 	I'm using CGI::Session::Test::Default right now. The tests there are
> in rather large blocks, and only a few things in a few blocks are failing
> with JSON... My first inclination is to either subclass that and copy and
> paste a bunch of stuff, or refactor Test::Default so that certain tests can
> be skipped. I'm thinking supplying our own ok() that runs the test by
> default, but skips it if it's in $self->{skip_tests}.

I like the idea of refactoring so that certain tests can be skipped. I
think the result will be easier to follow when you are done. 

Thanks for that grunt work!

	Mark