[cgiapp] : CGI::Session

[Nicholas Bamber]

Ron/Jason,

    

> Actually, anything and everything which give people information (on
> which to base decisions pertaining to their own lives) helps.


    Thanks for the information. This exactly describes my problem.

> Mark refuses to release until I make changes he insists on.

> The ostensible reason (as I understand it) is to do with auto-flushing
> or not when the object is destroyed. 

> My policy is that no user should be /forced/ to execute an explicit
> flush just before the object goes out of scope.

> The current code of sub DESTROY() doing a flush is fine as a default.

> In some cases, e.g. under Plack, the object (really the app) doesn't go
> out of scope when the app exits, and the user must use flush. But I
> don't accept that that is a reason to force all non-Plack uses to call
> flush. It simply doesn't make any sense.

I would have thought the correct thing to do is to maintain backwards compatibility but provide support for whatever behaviours
might be required. A simple switch to choose between the two behaviours. Maybe there could be a chance to choose the default between
the two behaviours at installation time. 

I also wonder if Mark feels that autoflushing at the end is unreliable and supporting it causes more trouble than it saves both for
the maintainer and users. That could be quite a defensible position.

> The current situation punishes everyone using the current CPAN version,

> which is the officially-released version, since we know many people work

> in orgs which will not condone installing from a remote svn or git etc repository.

Actually there is nothing to stop you from uploading a distribution to CPAN

with  a different name, but the same .pm files and forking that way. However I agree that that would be

an aggressive action and something of a bridge burning. 

> Mark won't give me co-main power. I suppose I could request it directly

> from CPAN admins. They might agree.

I doubt that they would agree. He still cares about the module and I imagine that is what counts.


> I'm suggesting the real matter should be dealt with in a (private)
> manner which does not sabotage release of past, present and future
> patches.

Yes could we also keep the discussion at a technical level and keep pyschobabble out of it. Noone wants their psychiatry  to be conducted on a public mailing list and it probably won't be conducive to a good outcome.