cgi-session-user — CGI::Session users mailing list

Re: [Cgi-session-user] HOWTO change the session file name

[Jeff C. <jch...@gm...>]

On 04/30/2010 05:36 PM, Jeff Chimene wrote:
> Hi:
>
> I'm trying to change the session file name.
>
> Given the following code:
> 	use CGI::Session::Driver::file;
> 	$CGI::Session::Driver::file::FileName = "%s.dat";
> 	die;
>
> I find a spurious session file. Is this expected behavior?
>   
Hi Ron:

Sorry, I cannot let this go.

Let's start negotiations with the following routine. The "found
spurious" message is in the log. The session file does load.

spurious session:   _SESSION_ATIME => 1272823871
legitimate session: _SESSION_ATIME => 1272823852

There is a "primary" session in $postdata; which provides  bootstrap
information necessary to retrieve the legitimate session.

I switched to "load()" from "new()" in an attempt to address this issue.

#%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
#
sub GetLocalReportState
##
##%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%%
{
    use File::Spec;
    use CGI::Session::Driver::file;
    $CGI::Session::Driver::file::FileName = "%s.dat";
    $i->param( 'report_id', $postdata->{report}->{report_id} || '' );
    $i->param( 'inspection_company_id', $postdata->{inspectionCompanyId} );
    my $dataPath = join( '', $CompanyDataPath,
$i->param('inspection_company_id'), '/reports/' );

    my $sessionFile = File::Spec->catfile(
        $dataPath    #
        , sprintf( $CGI::Session::Driver::file::FileName,
$i->param('report_id') )
    );

    if ( -e $sessionFile )
    {
        my $cgiSession = CGI::Session->load( "id:static",
$i->param('report_id'), { Directory => $dataPath } );
        $cgiSession->load_param($i);
        $logger->trace("found spurious session") if -e
$dataPath.$cgiSession->id().'.dat';
        $logger->logcroak(CGI::Session->errstr()) unless
CGI::Session->errstr() eq '';
        return 'OK';
    }
    $logger->logcroak("cannot find $sessionFile: $!");
} ## end sub GetLocalReportState

[Cgi-session-user] Session tutorial

[<ju...@vi...>]

Are there any other cgi::session tutorials besides cgi::session::tutorial, cookbook and other standard examples? 


Sent from my Verizon Wireless BlackBerry

Re: [Cgi-session-user] HOWTO change the session file name

[Jeff C. <jch...@gm...>]

On Fri, Apr 30, 2010 at 6:09 PM, Ron Savage <ro...@sa...> wrote:

> Hi Jeff
>
> On Fri, 2010-04-30 at 17:36 -0700, Jeff Chimene wrote:
> > Hi:
> >
> > I'm trying to change the session file name.
> >
> > Given the following code:
> >       use CGI::Session::Driver::file;
> >       $CGI::Session::Driver::file::FileName = "%s.dat";
> >       die;
> >
> > I find a spurious session file. Is this expected behavior?
>
> Should work.
>
> But did you use CGI::Session anywhere in the test?
>
> A call to generate a session object executed (using 'file') before the
> above code will negate the effect of the above.
>

Hi Ron,

I'm still getting a spurious session object. I'm sure that CGI::Session
works as designed. I'm going to take another approach to integrating
CGI::Session into this legacy app.

Re: [Cgi-session-user] HOWTO change the session file name

[Jeff C. <jch...@gm...>]

On Sat, May 1, 2010 at 6:49 AM, Jeff Chimene <jch...@gm...> wrote:

> The post was the "simplest" case. I omitted the call to load the session
> file. The purpose of this routine is the loading of an older session file.
> I've switched to "load" from "new' for this purpose. I saw this behavior
> because my "load" testing environment isn't 100%.
>
> This reactivation behavior has to be integrated into a legacy app; which
> expects session files with a certain naming convention, created using the
> CGI save() method.
>
> Thanks for the quick answer!
>
> Cheers,
> jec
>
>
> On Fri, Apr 30, 2010 at 6:09 PM, Ron Savage <ro...@sa...> wrote:
>
>> Hi Jeff
>>
>> On Fri, 2010-04-30 at 17:36 -0700, Jeff Chimene wrote:
>> > Hi:
>> >
>> > I'm trying to change the session file name.
>> >
>> > Given the following code:
>> >       use CGI::Session::Driver::file;
>> >       $CGI::Session::Driver::file::FileName = "%s.dat";
>> >       die;
>> >
>> > I find a spurious session file. Is this expected behavior?
>>
>> Should work.
>>
>> But did you use CGI::Session anywhere in the test?
>>
>> A call to generate a session object executed (using 'file') before the
>> above code will negate the effect of the above.
>>
>> --
>> Ron Savage
>> ro...@sa...
>> http://savage.net.au/index.html
>>
>>
>>
>>
>> ------------------------------------------------------------------------------
>> _______________________________________________
>> Cgi-session-user mailing list
>> Cgi...@li...
>> https://lists.sourceforge.net/lists/listinfo/cgi-session-user
>>
>
>

[Cgi-session-user] HOWTO change the session file name

[Jeff C. <jch...@gm...>]

Hi:

I'm trying to change the session file name.

Given the following code:
	use CGI::Session::Driver::file;
	$CGI::Session::Driver::file::FileName = "%s.dat";
	die;

I find a spurious session file. Is this expected behavior?

Re: [Cgi-session-user] Possible errors in the Cookbook.

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

On Mon, 19 Apr 2010 18:51:39 -0400
cg...@co... wrote:

> 
> As I said, I've moved on. But it might be nice if then it came down, 
> and didn't stay there to screw other people up.

I agree. However, the only person who currently has permission to
remove it, Sherzod, is no longer active here.

Still, it's a good idea to check that documentation you are reading
online approximately matches the version of the software that you have
installed. 

   Mark

Re: [Cgi-session-user] Possible errors in the Cookbook.

[<cg...@co...>]

As I said, I've moved on. But it might be nice if then it came down, 
and didn't stay there to screw other people up.

rick

At 06:36 PM 4/19/2010, Ron Savage wrote:
>Hi Rick
>
>On Sun, 2010-04-18 at 12:08 -0400, cg...@co... wrote:
> > http://search.cpan.org/~sherzodr/CGI-Session-3.95/Session/CookBook.p
>
>This file is no longer shipped as part of the distro. The git log I
>checked only said it was added in 2002. There was nothing about it being
>removed.
>
>Since CGI::Session has been updated often since then, I suggest you just
>forget that Cookbook.
>
>--
>Ron Savage
>ro...@sa...
>http://savage.net.au/index.html
>
>
>
>------------------------------------------------------------------------------
>Download Intel® Parallel Studio Eval
>Try the new software tools for yourself. Speed compiling, find bugs
>proactively, and fine-tune applications for parallel performance.
>See why Intel Parallel Studio got high marks during beta.
>http://p.sf.net/sfu/intel-sw-dev
>_______________________________________________
>Cgi-session-user mailing list
>Cgi...@li...
>https://lists.sourceforge.net/lists/listinfo/cgi-session-user

Re: [Cgi-session-user] Possible errors in the Cookbook.

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

> Mark Stosberg is refusing to release any more versions until he gets his
> way on a fight he thinks he's having with me over the auto-flush
> behaviour of the exit code. Sigh.

Hello,

It's true I haven't made a release in a timely manner, and I apologize
for that. I've made a note now to do so soon, or to follow-up further
with Ron.  I especially appreciate all the effort that Ron and others
put into maintaining this module. 

    Mark

Re: [Cgi-session-user] Possible errors in the Cookbook.

[<cg...@co...>]

Code works fine, it's just the cookbook that has issues. ...

Took me forever to figure out the code because of it, but I'm good now.

Rick


At 06:35 PM 4/18/2010, Ron Savage wrote:
>Hi Rick
>
>On Sun, 2010-04-18 at 12:08 -0400, cg...@co... wrote:
> >
> >
> > Seeing as how a cookbook is a lot less useful when the recipies are
> > wrong, I thought i"d pas along some observations about possible errors in
> > http://search.cpan.org/~sherzodr/CGI-Session-3.95/Session/CookBook.p
>
>[Chop bad code and good explanation].
>
>$many x $thanx;
>
>I'll clean up the code, since I do most of the maintenance on the module
>these days.
>
>However, don't expect to ever see it released.
>
>Mark Stosberg is refusing to release any more versions until he gets his
>way on a fight he thinks he's having with me over the auto-flush
>behaviour of the exit code. Sigh.
>
>Cheers...
>--
>Ron Savage
>ro...@sa...
>http://savage.net.au/index.html
>
>
>
>------------------------------------------------------------------------------
>Download Intel® Parallel Studio Eval
>Try the new software tools for yourself. Speed compiling, find bugs
>proactively, and fine-tune applications for parallel performance.
>See why Intel Parallel Studio got high marks during beta.
>http://p.sf.net/sfu/intel-sw-dev
>_______________________________________________
>Cgi-session-user mailing list
>Cgi...@li...
>https://lists.sourceforge.net/lists/listinfo/cgi-session-user

[Cgi-session-user] Possible errors in the Cookbook.

[<cg...@co...>]

Seeing as how a cookbook is a lot less useful when the recipies are 
wrong, I thought i"d pas along some observations about possible errors in
http://search.cpan.org/~sherzodr/CGI-Session-3.95/Session/CookBook.p

Item 1:
It says that you issue:
init($cgi, $session);

But in the actual subroutine init {} it imports the values as :

my ($session, $cgi) = @_; # receive two args

(So $session and $cgi are reversed)

Item 2:
Typos
To deal with this very important usabilit feature, you need to 
include a hiidden field in your login form similar to:

"usabilit" > "usability"
"hiidden" > "hidden"

Item 3:
         print error("You failed 3 times in a row.\n" .
                     "Your session is blocked. Please contact us with ".
                     "the details of your action");

doesn't actually print anything.
print ("You failed 3 times in a row.\n" .  "Your session is blocked. 
Please contact us with ".  "the details of your action");

does.

Item 4:
print login_page($cgi, $session);

Problem 1: an example login_page {} sub isn't included in the 
Cookbook, which makes it less cookbook-like.

Problem 2: Depending on how you write that sub (I wrote one that 
outputs a login page) it returns 1; which means on each page you get 
a "1" at the bottom.

Instead, if should probably be:
login_page($cgi, $session);

but it varies on how you solve the fact that login_page{} isn't in 
the Cookbook.

Item 5:
sub _load_profile { }
         unless (sysopen(PROFILE, "profiles.txt", O_RDONLY) ) {
             die "Couldn't open profiles.txt: $!");
         }
         while ( <PROFILES> ) {
It should be <PROFILE> not <PROFILES>








Rick Steeves
http://www.sinister.net

In reality nothing is more damaging to the adventurous spirit within 
a man than a secure future -  Alexander Supertramp

[Cgi-session-user] Fwd: HOWTO get same session

[Jeff C. <jch...@gm...>]

Duh.

---------- Forwarded message ----------
From: Jeff Chimene <jch...@gm...>
Date: Mon, Apr 12, 2010 at 11:26 PM
Subject: Re: [Cgi-session-user] HOWTO get same session
To: Ron Savage <ro...@sa...>


Yes, that seems more like what I want. My apologies for the lack of
precision in point 2 of the original post.

As an aside, I'm sure you can explain the side effect in the following code.
As is, it yields two identical session IDs. Removing the braces yields two
separate session IDs. As I've been playing w/ CGI::Session in a test
harness, I wasn't expecting to need to use a separate expression each time I
created a CGI::Session

Thanks for your patience!

#!/usr/bin/perl -w

use strict;


use CGI;
use CGI::Session;

my ($q, $id_1 );
$q = CGI->new;

{
    my $session = CGI::Session->new( undef, $q, {}, { name => 'X' } );
    $id_1 = $session->id;

    print "1. id: $id_1. \n";
}

$q->param( X => $id_1 );

print "2. id: ".CGI::Session->new( undef, $q, {}, { name => 'X' }
)->id()."\n";


On Mon, Apr 12, 2010 at 11:12 PM, Ron Savage <ro...@sa...> wrote:

> Hi Jeff
>
> Damn: Default is to /not/ send to the list.
>
> On Mon, 2010-04-12 at 21:44 -0700, Jeff Chimene wrote:
> >
> >
> > On Mon, Apr 12, 2010 at 8:29 PM, Ron Savage <ro...@sa...> wrote:
> >         Hi Jeff
> >
> >         On Mon, 2010-04-12 at 16:22 -0700, Jeff Chimene wrote:
> >         > Hi:
>
> > Hi Ron:
> >
> > Do you have an example that produces a file name "cgisess_x"? It looks
> > like this can happen, but I cannot figure out how to achieve that.
> > Your provided example doesn't yield a file named "cgisess_x".
>
> Ahhh, so that's what you want. You did not say that before :-(.
>
> Go here
>
> http://search.cpan.org/~markstos/CGI-Session-4.42/<http://search.cpan.org/%7Emarkstos/CGI-Session-4.42/>
>
> and you'll see a module called CGI::Session::ID::static. Perhaps that's
> what you want.
>
>
> --
> Ron Savage
> ro...@sa...
> http://savage.net.au/index.html
>
>
>
>
> ------------------------------------------------------------------------------
> Download Intel&#174; Parallel Studio Eval
> Try the new software tools for yourself. Speed compiling, find bugs
> proactively, and fine-tune applications for parallel performance.
> See why Intel Parallel Studio got high marks during beta.
> http://p.sf.net/sfu/intel-sw-dev
> _______________________________________________
> Cgi-session-user mailing list
> Cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgi-session-user
>

[Cgi-session-user] HOWTO get same session

[Jeff C. <jch...@gm...>]

Hi:

I'm trying to reload a session where I supply the id. I see that
_CLAIMED_ID is set to my specified value.

However:
1) I get a new session each time
2) The session name is not the value I want.

I'd be grateful for any assistance.

=== CODE ===

my $cgi = new CGI;
my $session = CGI::Session->new($cgi);

$logger->trace($session->id());

undef $session;

$session = CGI::Session->new($cgi);
$logger->trace($session->id());

Here are the commands and output

$ rm /tmp/cgisess*
removed `/tmp/cgisess_41e4262ce352f8e49aa1e0042fe7ab71'
removed `/tmp/cgisess_8afb60d809d1d89c32d74166a011e057'
removed `/tmp/cgisess_b6946b678e4dbb06a03c49ff070fecbe'
removed `/tmp/cgisess_dc35224293ff80887caa3d3731b3c07e'

$ ./sessionTest.cgi /test?CGISESSID=FRED

$ cat /tmp/session.log
2010/04/12 16:16:42 TRACE> sessionTest.cgi:32 main:: -
0368568c359f8f301c9217f8b0e59ee3
2010/04/12 16:16:42 TRACE> sessionTest.cgi:39 main:: -
eda0ea720620e1cf359c15e01a634280

$ ls /tmp/cgisess*
/tmp/cgisess_0368568c359f8f301c9217f8b0e59ee3
/tmp/cgisess_eda0ea720620e1cf359c15e01a634280

Re: [Cgi-session-user] cgisess_* files removal

[michael k. <ko...@gm...>]

To ask the other way around: Does CGI::Session deletes all variables
saved with CGI::Session->param call when forcfully expiring it with
CGI::Session::ExpireSession?

Re: [Cgi-session-user] cgisess_* files removal

[michael k. <ko...@gm...>]

I'm storing custom class object. Currently with the help of
CGI::Session: $cgi->save("obj", $obj);
I want to keep the object alive between multiple executes of the CGI script.
I implemented Perl interface to interact with hardware devices, namely
ELT::Switch::3Com module. There are many of devices, so each web page
should deal with only single device. So one daemon won't do. Only one
daemon for each web page which sounds strange.

Re: [Cgi-session-user] cgisess_* files removal

[michael k. <ko...@gm...>]

I tried your module and it worked fine:

#!/usr/bin/perl
use strict;
use warnings;
use CGI::Session::ExpireSessions;

my $expirer = new CGI::Session::ExpireSessions(temp_dir => "/tmp",
                                               delta => 60);
$expirer->expire_file_sessions();

All expired files has been removed.
I have another problem. I initialize custom object which I want to
keep alive between web page updates for the duration of a session. And
upon its expiration I want to deinitialize it. Is there any way to
achieve that with your module?
Thanks.

[Cgi-session-user] cgisess_* files removal

[michael k. <ko...@gm...>]

Hello.
I'm using CGI::Session under Apache2. Each time new session is created
the cgisess_* file is created (I use file driver), but then it is
never removed.
The file is removed only when $session->delete() is called, but the
only thing I'm able to do is set expiration to 1 minute. How to make
the files disappear automatically?
Thanks.

Re: [Cgi-session-user] The future of CGI::Session

[Jonathan S. <sw...@po...>]

I'd vote against an inside-out object scheme, personally, because they  
tend to exist in their own sparsely populated universes and be  
difficult to combine with other classes.

I've no doubt Hash::FieldHash has marvellous properties as you say,  
but it seems very lightly used - http://cpants.perl.org/dist/used_by/Hash-FieldHash

Plain old blessed hashes certainly have their issues, but people will  
be able to subclass them easily and even use Moose for their  
subclasses if they choose.

Jon

>
> ObjectModel
>
> o Should any object helper code be adopted? Yes.
>
> o I don't think it's appropriate to use Moose,say, since some people
> would be unhappy with the overhead.
>
> o I'd choose the marvellous Hash::FieldHash as seemingly the lightest
> and best among a ridiculously large array of possibilities.
>
> ParameterChecking
>
> o Should Params::Validate or somesuch be adopted to validate  
> parameters?
> Yes.
>
> o Should the current mechanism of overloaded method calls be  
> supported?
> No.
>
> o By this ('current mechanism') I mean the code has to analyze the
> actual parameter list to determine what type the parameters are, and
> hence what the caller's intent is.
>
> PerlSix
>
> o Should the new version be just for Perl 5, or just for Perl 6?
>
> o I say perl 5, since it's going to be in use for many a long year.
>
>
> SubDelete
>
> o sub delete is never called, and can be circumvented by calls to
> _set_status and _unset_status.
>
> o Do we need it?
>
> [1] http://tiddlywiki.org/wiki/Main_Page
>
> -- 
> Ron Savage
> ro...@sa...
> http://savage.net.au/index.html
>
>
>
> ------------------------------------------------------------------------------
> The Planet: dedicated and managed hosting, cloud storage, colocation
> Stay online with enterprise data centers and the best network in the  
> business
> Choose flexible plans and management services without long-term  
> contracts
> Personal 24x7 support from experience hosting pros just a phone call  
> away.
> http://p.sf.net/sfu/theplanet-com
> _______________________________________________
> Cgi-session-user mailing list
> Cgi...@li...
> https://lists.sourceforge.net/lists/listinfo/cgi-session-user

Re: [Cgi-session-user] HOWTO: Change the directory for the session file

[Jeff C. <jch...@gm...>]

On 02/08/2010 02:55 PM, Ron Savage wrote:
> Hi Jeff
> 
> On Mon, 2010-02-08 at 01:17 -0700, Jeff Chimene wrote:
> [snip]
> 
> You're better off calling new(undef, CGI -> new, ...) always, and to let
> the module call load.
> 
> Here's what I do in App::Office::Contacts, under /all/ circumstances:
> 
> 	# Set up the session.
> 
> 	$self -> param(session =>
> 	CGI::Session -> new
> 	(
> 		${$self -> param('config')}{'session_driver'},
> 		$q,
> 		{
> 			Handle    => $self -> param('db') -> dbh,
> 			TableName => ${$self -> param('config')}{'session_table_name'},
> 		},
> 		{
> 			name => 'sid',
> 		}
> 	) );
> 
> According to the docs, new defaults to creating a session, load does
> not.

Right. That's the behavior I want.

> 
> Inside the distro there is a test, t/24285.t, which uses this feature.
> Examine that first.
> 
> Also, below is code from a new test (not on CPAN, but in the
> repository), called t/modified.t.
> 
> Notice how new() is called, and it calls load() if necessary, to get
> started. 
which is what I want. I was unclear that new() automatically called load().

Thanks for the help. I have this working now.

[Cgi-session-user] HOWTO: Change the directory for the session file

[Jeff C. <jch...@gm...>]

Hi:

I've been using CGI::Session for almost a year.  I'd like to move the
session file to a private directory.

I'm currently using the following version:
$CGI::Session::VERSION  = '4.41';

The pattern I use is:
$session = CGI::Session->load() or die CGI::Session->errstr();

$_ = $cgi->path_info();

CASE:
{
    if ( $session->is_expired )
    {
        print jsonStatus(q/%F-TMO-Your session timed out! Refresh the screen
to start new session!/);
        last CASE;
    }

    /^\/login$/i and do
    {
        if ( $session->is_empty )
        {
            $session = CGI::Session->new() or die CGI::Session->errstr();
#
# jsonStatus calls $session->header()
#
            print jsonStatus(q/%S-SUCCESS-Successful login/);
            last CASE;
        } ## end if ( $session->is_empty...)
    };

    if ( ( $session->id() || q// ) ne $sid )
    {
        print jsonStatus(q/%F-SESSNOTFND-expected session not found/);
        last CASE;
    } ## end if ( ( $session->id() ...))

I'd hoped to merely change the load() to
$session = CGI::Session->load(undef,undef,{Directory => q?../session?})

and change the new() to
$session = CGI::Session->new(undef, cgi->new, {Directory => q?../session?})

obviously, this doesn't work No session file is created after the new()
call; the $session->id() after the load() is undef when $sid has a legal
session id.

I've also tried replacing the 2nd undef in the call to load() with the
current $sid.

What's the correct way to move the session file to a non-default directory?

tia,

Re: [Cgi-session-user] writing CGI::Session sessions only when necessary

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

> Firstly I'd like the current patches to be released, perhaps with a doc
> patch warning about the impending flush change.
> 
> Then, for disabling flush, I'd think there should be both of these:
> o A option to new and load to turn off auto-flush
> o A new method so the user could control auto-flush after calling new.

I agree something along these lines would be reasonable. 

> Also, if we jump to V 5.0, I'd like to take the opportunity to eliminate
> all global variables from the code.

That also sounds good to me.

Ron, could you commit your most recent changes to our changed github
repo?

http://github.com/cromedome/cgi-session

    Mark

-- 
 . . . . . . . . . . . . . . . . . . . . . . . . . . . 
   Mark Stosberg            Principal Developer  
   ma...@su...     Summersault, LLC     
   765-939-9301 ext 202     database driven websites
 . . . . . http://www.summersault.com/ . . . . . . . .

Re: [Cgi-session-user] writing CGI::Session sessions only when necessary

[Jonathan S. <sw...@po...>]

On Feb 2, 2010, at 8:27 PM, Ron Savage wrote:

> o If your code is written properly, there is no need to call flush().
>
> The session object's DESTROY() method calls flush().
>
> People had problems because their database handle was going out of  
> scope
> before the session object.
>
> Others had problems because they created circular data structures, so
> their program did not exit cleanly.
>
> o flush() is called from DESTROY(), close() and even load().
>
> So, you might not call it explicitly, but it can still be called in
> other ways.
>

Yes, I'm aware of that. I called flush() in my code example just to  
make it explicit.

I agree with Mark that there should be a way to turn off the automatic  
flushing behavior, rather than having to jump through hoops to do so.  
It's analagous to DBI's autocommit.

> o New methods allow you to reset the modified flag if nothing but the
> session's access time has changed, /if you think that's a good idea/.
>
> See the docs for is_params_modified() and reset_modified().

Ok. Wouldn't it be simpler, though, to be able to specify "don't  
update the access time"? I *never* look at the access time and I'll  
bet I'm not alone.

Thanks for working on this!

Jon

Re: [Cgi-session-user] writing CGI::Session sessions only when necessary

[Jonathan S. <sw...@po...>]

On Feb 3, 2010, at 6:39 AM, Mark Stosberg wrote:

>
> Thanks for your work on this, Ron.
>
>> The session object's DESTROY() method calls flush().
>
> This to me seems to illustrate another case where the automatic
> DESTROY() behavior is a bad idea.
>
> Not only does it not always work reliably, here's a case where someone
> legitimately doesn't want to the session to flush unless they say so,
> and extra hoops and code are required to suppress the automatic
> behavior.
>
> I have some mind to recommend releasing a "5.0" version which removes
> automatic flushing behavior. (With a clear note in "Changes"). At this
> point we've already been documenting and recommending explicit  
> flushing
> for about 2 years.
>
> Jon,  would being explicitly able to control when a flush() happens
> help your case, or do you still see the need to add extra methods to
> address this?
>

That will take care of the latter half of it, so it would help, yes.

For the first half I still would need the is_modified() method, and to  
pass 0 as the fourth argument to load() for $update_atime (which works  
fine, just isn't documented).

Thanks
Jon

Re: [Cgi-session-user] writing CGI::Session sessions only when necessary

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

Thanks for your work on this, Ron. 

> The session object's DESTROY() method calls flush().

This to me seems to illustrate another case where the automatic
DESTROY() behavior is a bad idea. 

Not only does it not always work reliably, here's a case where someone
legitimately doesn't want to the session to flush unless they say so,
and extra hoops and code are required to suppress the automatic
behavior. 

I have some mind to recommend releasing a "5.0" version which removes
automatic flushing behavior. (With a clear note in "Changes"). At this
point we've already been documenting and recommending explicit flushing
for about 2 years. 

Jon,  would being explicitly able to control when a flush() happens
help your case, or do you still see the need to add extra methods to
address this? 

    Mark

Re: [Cgi-session-user] writing CGI::Session sessions only when necessary

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

On Tue, 02 Feb 2010 09:54:29 +1100
Ron Savage <ro...@sa...> wrote:

> Hi Folks
> 
> OK. I'm starting to look at this issue.
> 
> The first problem is that on CPAN the latest version is 4.42, but in my
> repository I have 4.44. AFAICT, 4.43 and 4.44 have not been released.
> 
> Mark, are you in a position to release a new version if I make patches?

Yes. Thanks. 

   Mark

Re: [Cgi-session-user] writing CGI::Session sessions only when necessary

[<ro...@sa...>]

Hi Mark

My replies to Jon have not been copied to the list.

Briefly, my contract finishes tomorrow (Friday), so I'll investigate  
patches ASAP.