Stuff with the Perl Foundation. A couple of patches in the Perl core. A few CPAN modules. That about sums it up.
Much fun was had today. I needed some session management for a site with vague specs and I'm not sure what data to capture. I generally don't enjoy stuffing too much data into a session, but I needed to get this stuff running quickly, with the caveat that other pages on this site might want to share the session id to avoid setting multiple cookies. But if I do that, how do easily prevent accidentally overwriting session data in the database?
My sessions now have their own namespaces. It's based on CGI::Session and is mostly transparent to the programmer. You can have 28 different programs setting a session parameter named "total", all of them using the same session, but each maintaining a distinct total, if necessary. But if they need to share the data? Create a new session object explicitly naming the namespace from which you want to get the data:
my $session = My::Session->new($cgi, 'some_namespace');
If you leave the namespace off, it defaults to sprintf("%s::%s", $0, $calling_package);.
I'm not entirely sure that's a great idea, but it's quite handy.
Re: Session Namespaces (Score:1)
Code availability? (Score:1)
Re:Code availability? (Score:2)
It's not likely for a couple of reasons. First, this code was written on someone else's dime and has some customization for their needs. It belongs to them. I'd have to reimplement it from scratch. To make it a more general tool, I'd still need to change a few things about it.
The other reason is a bit odd: many people abuse how cookies are used and making them a more flexible tool might encourage that abuse. Using a cookie this way can make it easier for a domain to set only one cookie (with the ses
Easy to Abuse (Score:1)
Maybe the problem isn't that you could stick all of your data in a hashref and bless it. Maybe the problem is that you don't pull it into saner pieces when you need it to be in saner pieces.