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

Re: [Cgi-session-user] Progress report on all RT bug reports

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

I have now reviewed the "diffs" of all of Ron's commits for this round of
bugfixing, and they all look good. Thanks, Ron!

Currently I'm waiting on renewed "commit" access myself, and then I plan
to publish a 4.29_1 release with Ron's changes, for wider testing.

After about a week (assuming nothing unexpected comes up), I think it
would be appropriate to release 4.30 then.

     Mark

Re: [Cgi-session-user] Session not working (not restoring a previously set session)

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

Hi Mattia

> #use strict;
> use CGI;
> use CGI::Carp ('fatalsToBrowser');
> use CGI::Session;
> use DBI;
> $cgi = new CGI;

This creates an object of type CGI.

> print $cgi->header('text/html');
>  $query = CGI->new();

This also creates an object of type CGI. Why are you doing this? You
only need 1 per program.

I don't know it that's the problem, but fix that first and tell us what
happens.

-- 
Ron Savage
ro...@sa...
http://savage.net.au/index.html

Re: [Cgi-session-user] Session not working (not restoring a previously set session)

[mattia <mat...@gm...>]

Forgot to mention

I am only using one page which I refresh in order to set my test variable in
session

On Fri, Mar 14, 2008 at 5:02 PM, mattia <mat...@gm...> wrote:

> Hello session folks,
>
> This is my first post in this list
>
> I found the code in the post at
> http://osdir.com/ml/lang.perl.modules.cgi-session.user/2005-09/msg00031.html
> I used the example by Sherzod Ruzmetov and it works fine..
>
> Now, my code is the following and it does not work. I have spent the whole
> day on this issue which in PHP I had solved in 5 minutes..
> Can some one please help me out?
> The main thing is that I remove the *use strict* directive from the
> example as I dont want to use it ( I guess Session should not depend on this
> right??)
> The code I post is just a part and if I decide to put in use strict I
> would have to change all variable declarations adding the "*my*" before
> the declarations (and so in my other scripts pertaining a whole
> application..  I dont want to do this :( )
> I hence removes also all the "my" prefixes..
> *
> #use strict;
> use CGI;
> use CGI::Carp ('fatalsToBrowser');
> use CGI::Session;
> use DBI;
> $cgi = new CGI;
> print $cgi->header('text/html');
>  $query = CGI->new();
>  $session = CGI::Session->new(undef, $cgi, {Directory=>'/tmp'});
>  $cookie = $query->cookie(-name=>$session->name,
> -value=>$session->id,-expires=>"+1h");
> print $query->header(-cookie=>$cookie);
>
> # session id keeps changing @) !!!
> print $session->id . "<br />";
>
> if ($session->param("test_var")) {
>   print "retrieving variable from session" .  $session->param("test_var");
> }
> else {
>   print "set example variable in session";
>   $session->param("test_var", "hello damn session");
> }*
>
>
> PS: I have tried with versions 3.95, 4.10 and 4.20!!
>
> Thanks in advance
>
>
> --
> Mattia




-- 
Mattia

[Cgi-session-user] Session not working (not restoring a previously set session)

[mattia <mat...@gm...>]

Hello session folks,

This is my first post in this list

I found the code in the post at
http://osdir.com/ml/lang.perl.modules.cgi-session.user/2005-09/msg00031.html
I used the example by Sherzod Ruzmetov and it works fine..

Now, my code is the following and it does not work. I have spent the whole
day on this issue which in PHP I had solved in 5 minutes..
Can some one please help me out?
The main thing is that I remove the *use strict* directive from the example
as I dont want to use it ( I guess Session should not depend on this
right??)
The code I post is just a part and if I decide to put in use strict I would
have to change all variable declarations adding the "*my*" before the
declarations (and so in my other scripts pertaining a whole application..  I
dont want to do this :( )
I hence removes also all the "my" prefixes..
*
#use strict;
use CGI;
use CGI::Carp ('fatalsToBrowser');
use CGI::Session;
use DBI;
$cgi = new CGI;
print $cgi->header('text/html');
 $query = CGI->new();
 $session = CGI::Session->new(undef, $cgi, {Directory=>'/tmp'});
 $cookie = $query->cookie(-name=>$session->name,
-value=>$session->id,-expires=>"+1h");
print $query->header(-cookie=>$cookie);

# session id keeps changing @) !!!
print $session->id . "<br />";

if ($session->param("test_var")) {
  print "retrieving variable from session" .  $session->param("test_var");
}
else {
  print "set example variable in session";
  $session->param("test_var", "hello damn session");
}*


PS: I have tried with versions 3.95, 4.10 and 4.20!!

Thanks in advance


-- 
Mattia

Re: [Cgi-session-user] JSON problems as per RT bug 25325

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

Hi Mark

> I have now main you a CO-MAINT of this name space, which will hopefully 
> make the "** UNAUTHORIZED RELEASE **" status on CPAN go away.

Thanx. I went here

http://search.cpan.org/~rsavage/CGI-Session-Serialize-yaml-4.21/

and there's no big red notice, and going to PAUSE and viewing permssions
all looks good too. $many x $thanx;

> It would be nice but not necessary if the Build or Makefile.PL offered 
> to install YAML or YAML::Syck for you, but that's not a feature we had 
> before and I'm happy to continue to live without it.

That's the ideal. I've never needed a Build.PL or Makefile.PL which
asked the user for optional extras, but I can look into it.
-- 
Ron Savage
ro...@sa...
http://savage.net.au/index.html

Re: [Cgi-session-user] JSON problems as per RT bug 25325

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

> 
> CGI::Session::Serialize::yaml V 4.21 has been uploaded to CPAN.
> 
> It contains Build.PL too, for those who prefer Module::Build.
> 
> Note: The pre-req is for CGI::Session V 4.20 not V 4.21 so you can
> install this new distro without upgrading CGI::Session to V 4.21.
> See the Changes file for why what's known to be pointless but still
> possible.

Thanks, Ron!

I have now main you a CO-MAINT of this name space, which will hopefully 
make the "** UNAUTHORIZED RELEASE **" status on CPAN go away.

It would be nice but not necessary if the Build or Makefile.PL offered 
to install YAML or YAML::Syck for you, but that's not a feature we had 
before and I'm happy to continue to live without it.

Thanks again for your help on this!

    Mark

Re: [Cgi-session-user] Progress report on all RT bug reports

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

Hi Folks

Yet Another Progress Report.

> > 15)
> > RT: http://rt.cpan.org/Public/Bug/Display.html?id=2224
> > 

Fixed. Supported drivers:
o MySQL
o ODBC (separate distro)
o Oracle (separate distro)
o Postgres
o SQLite

-- 
Ron Savage
ro...@sa...
http://savage.net.au/index.html

Re: [Cgi-session-user] JSON problems as per RT bug 25325

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

Hi Mark

But note:

Status: Permission missing
==========================

     module: CGI::Session::Serialize::yaml
    version: 4.21
    in file:
CGI-Session-Serialize-yaml-4.21/lib/CGI/Session/Serialize/yaml.pm
     status: Not indexed because permissions missing. Visit PAUSE and
             click "View Permissions" to find the legitimate
             maintainer(s).

-- 
Ron Savage
ro...@sa...
http://savage.net.au/index.html

Re: [Cgi-session-user] JSON problems as per RT bug 25325

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

Hi Mark

> > I'll wait till you reply, but is it ok then to wipe out all trace of
> > YAML?
> 
> Yes.

CGI::Session without YAML has been checked in to SVN.

> > At the same time of course I'll look at splitting YAML stuff into a
> > separate distro.

CGI::Session::Serialize::yaml V 4.21 has been uploaded to CPAN.

It contains Build.PL too, for those who prefer Module::Build.

Note: The pre-req is for CGI::Session V 4.20 not V 4.21 so you can
install this new distro without upgrading CGI::Session to V 4.21.
See the Changes file for why what's known to be pointless but still
possible.
-- 
Ron Savage
ro...@sa...
http://savage.net.au/index.html

Re: [Cgi-session-user] Plug-ins for CGI::Session

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

Hi Mark

On Wed, 2008-03-12 at 17:47 -0400, Mark Stosberg wrote:
> Ron Savage wrote:
> > Hi Folks
> > 
> > These are some thoughts I had on plug-ins.
> > 
> > 1)
> > Does it make sense to define:
> > - A set of plug-ins for serialization
> > - A set of plug-ins for storage
> > - A set of plug-ins for id generation
> > 
> > 2)
> > If so, which plug-in technology is (wait for it!) 'best'.
> > 
> > Best is easily defined as 100% reliable (without too much overhead).
> > If the choice is up to me (it isn't) reliability is the only thing which
> > matters.
> 
> Ron,
> 
> I'm not sure what you are suggesting that isn't already there. As the 
> "PureSQL" driver/serializer demonstrates, it's already possible and 
> fairly clean to distribute these things externally and "plug them in" 
> when needed.

I was merely fishing for ideas, to see if anyone was un/satisfied with
the current system, or had suggestions for alternative ways of doing
things...

-- 
Ron Savage
ro...@sa...
http://savage.net.au/index.html

Re: [Cgi-session-user] JSON problems as per RT bug 25325

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

>> The Makefile.PL could declare YAML as a feature. If you choose it, you 
>> get the latest versions of YAML.
> 
> Is there a specific syntax for this? I did not see anything in the
> ExtUtils::MakeMaker POD. I'll create a Build.PL as an experiment, but if
> it refers to optional modules, it won't be compatible with Makefile.PL.

I think I must be thinking of "Module::Install" style Makefile.PL files.
It may be easier to break it out into a separate distro than get into a 
Makefile.PL overhaul.

>> Still, I could see how breaking it out as different distribution could 
>> be cleaner, and could still be an optional feature.
> 
> OK.
> 
>> I don't think removing JSON or YAML in a future version would cause 
>> breakage for people who upgrade, because as far as I'm aware Perl 
>> installations don't delete files from previous versions, so the JSON and 
>> YAML drivers would remain on disk.  It would only become a problem on an 
>> upgrade via "clean install".
>>
>> In sum, as long as you are working on it Ron it's fine with me to steer 
>> the solution towards your own inclinations, but I'm happy to be a 
>> sounding board if you are uncertain about what seems best.
> 
> I'll wait till you reply, but is it ok then to wipe out all trace of
> YAML?

Yes.

> At the same time of course I'll look at splitting YAML stuff into a
> separate distro.

Great!

   Mark

Re: [Cgi-session-user] Plug-ins for CGI::Session

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

Ron Savage wrote:
> Hi Folks
> 
> These are some thoughts I had on plug-ins.
> 
> 1)
> Does it make sense to define:
> - A set of plug-ins for serialization
> - A set of plug-ins for storage
> - A set of plug-ins for id generation
> 
> 2)
> If so, which plug-in technology is (wait for it!) 'best'.
> 
> Best is easily defined as 100% reliable (without too much overhead).
> If the choice is up to me (it isn't) reliability is the only thing which
> matters.

Ron,

I'm not sure what you are suggesting that isn't already there. As the 
"PureSQL" driver/serializer demonstrates, it's already possible and 
fairly clean to distribute these things externally and "plug them in" 
when needed.

   Mark

Re: [Cgi-session-user] Progress report on all RT bug reports

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

Hi Folks

Here's another progress report:

2)
RT: http://rt.cpan.org/Public/Bug/Display.html?id=33437

Patched repository via svn.

-- 
Ron Savage
ro...@sa...
http://savage.net.au/index.html

[Cgi-session-user] Plug-ins for CGI::Session

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

Hi Folks

These are some thoughts I had on plug-ins.

1)
Does it make sense to define:
- A set of plug-ins for serialization
- A set of plug-ins for storage
- A set of plug-ins for id generation

2)
If so, which plug-in technology is (wait for it!) 'best'.

Best is easily defined as 100% reliable (without too much overhead).
If the choice is up to me (it isn't) reliability is the only thing which
matters.

As a relevant note I seem to remember rjbs in his journal mentioned a
disaster he'd had with Module::Pluggable, such that after adopting it
he'd had to rip it all out again. IIRC He gave no other details at the
time.

-- 
Ron Savage
ro...@sa...
http://savage.net.au/index.html

Re: [Cgi-session-user] JSON problems as per RT bug 25325

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

Hi Mark

> I have used the YAML driver at least once myself and some interest in 
> seeing it maintained.  I mind less that it is in the core.

OK.

> The Makefile.PL could declare YAML as a feature. If you choose it, you 
> get the latest versions of YAML.

Is there a specific syntax for this? I did not see anything in the
ExtUtils::MakeMaker POD. I'll create a Build.PL as an experiment, but if
it refers to optional modules, it won't be compatible with Makefile.PL.

> Still, I could see how breaking it out as different distribution could 
> be cleaner, and could still be an optional feature.

OK.

> I don't think removing JSON or YAML in a future version would cause 
> breakage for people who upgrade, because as far as I'm aware Perl 
> installations don't delete files from previous versions, so the JSON and 
> YAML drivers would remain on disk.  It would only become a problem on an 
> upgrade via "clean install".
> 
> In sum, as long as you are working on it Ron it's fine with me to steer 
> the solution towards your own inclinations, but I'm happy to be a 
> sounding board if you are uncertain about what seems best.

I'll wait till you reply, but is it ok then to wipe out all trace of
YAML?

At the same time of course I'll look at splitting YAML stuff into a
separate distro.

Also, I'll post a separate msg to the list about some thoughts on
plug-ins.

-- 
Ron Savage
ro...@sa...
http://savage.net.au/index.html

Re: [Cgi-session-user] Progress report on all RT bug reports

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

Hi Folks

Here's a progress report:

On Fri, 2008-03-07 at 16:40 +1100, Ron Savage wrote:
> Hi Folks
> 
> I had a look at the bug list for CGI::Session on RT, and it gave me a
> fright, so I decided to do something about it.
> 
> I've gathered the suggestions from RT and various test file patches of
> my own, so come up with this status report:
> 
> 1)
> RT: http://rt.cpan.org/Public/Bug/Display.html?id=33635
> 
> Status: Not yet investigated
> 
> Next: Should have time next week to investigate


Patched repository via svn.


> 2)
> RT: http://rt.cpan.org/Public/Bug/Display.html?id=33437
> 
> Status: Patch applied, but it breaks name.t
> 
> Next: Should have time next week to investigate


No progress.


> 3)
> RT: http://rt.cpan.org/Public/Bug/Display.html?id=29138
> 
> Status: Can be closed. Patched successfully as per RT


Patched repository via svn.


> 4)
> RT: http://rt.cpan.org/Public/Bug/Display.html?id=32932
> 
> Status: Not yet investigated
> 
> Next: Should have time next week to investigate


Patched repository via svn.


> 5)
> RT: http://rt.cpan.org/Public/Bug/Display.html?id=29969
> 
> Status: Can be closed. I've successfully patched various test programs


Patched repository via svn.


> 6)
> RT: http://rt.cpan.org/Public/Bug/Display.html?id=25325
> 
> Context: JSON
> 
> Status: Not yet investigated. See separate email thread
> 
> Next: Should have time next week to investigate


Patched repository via svn.


> 7)
> RT: http://rt.cpan.org/Public/Bug/Display.html?id=28516
> 
> Context: Utf8
> 
> Status: New test written. See seperate email thread


Patched repository via svn.


> 8)
> RT: http://rt.cpan.org/Public/Bug/Display.html?id=17299
> 
> Context: Auto-flush
> 
> Status: Still open


No progress.


> 9)
> RT: http://rt.cpan.org/Public/Bug/Display.html?id=24601
> 
> Status: Can be closed. Patched successfully as per RT


Patched repository via svn.


> 10)
> RT: http://rt.cpan.org/Public/Bug/Display.html?id=24355
> 
> Status: Can be closed. Patched successfully as per RT


Patched repository via svn.


> 11)
> RT: http://rt.cpan.org/Public/Bug/Display.html?id=24285
> 
> Status: Can be closed. New test written. Original code now works
anyway


Patched repository via svn.


> 12)
> RT: http://rt.cpan.org/Public/Bug/Display.html?id=23597
> 
> Status: Can be closed. User error!


No patch required.


> 13)
> RT: http://rt.cpan.org/Public/Bug/Display.html?id=17541
> 
> Status: See (8) above re 17299


No progress.


> 14)
> RT: http://rt.cpan.org/Public/Bug/Display.html?id=18948
> 
> Status: Still open
> 
> Next: Should have time next week to investigate


No progress.


> 15)
> RT: http://rt.cpan.org/Public/Bug/Display.html?id=2224
> 
> Status: Still open
> 
> Next: Should have time next week to investigate (using Pg)


No progress.


> 16)
> RT: http://rt.cpan.org/Public/Bug/Display.html?id=21981
> 
> Status: See (7) above re 28516


Patched repository via svn.


> In a few days I'll upload to my web site a set of patch files against
V
> 4.20 for people to play with.

No I won't. From the docs:

=head1 PUBLIC CODE REPOSITORY

You can see what the developers have been up to since the last release
by
checking out the code repository. You can browse the Subversion
repository from here:

 http://svn.cromedome.net/repos/CGI-Session

Or check it directly with C<svn> from here:

 svn checkout http://svn.cromedome.net/repos/CGI-Session

-- 
Ron Savage
ro...@sa...
http://savage.net.au/index.html

[Cgi-session-user] Help: Programming Problem

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

Hi Folks

In the repository there is a program t/bug21981.

If I run it from the command line with:
shell> perl t/bug21981
the output is:

ok 1 - use CGI::Session;
ok 2 - use CGI::Session::Driver;
ok 3 - use CGI::Session::Driver::file;
ok 4 - Created CGI::Session object successfully
ok 5 - Session created successfully
	(in cleanup) Can't locate object method "renewed" via package
"Encode::utf8" (perhaps you forgot to load "Encode::utf8"?) at (eval 19)
line 1.
ok 6 - Warning: Failed to recreate session. Cannot "use 'utf8'; in
conjunction with CGI::Session"
1..6

which is what I want. If I run it with:
shell> make test
the output is:

t/bug21981........................1/0 Can't locate package
Encode::Encoding for @Encode::utf8::ISA at (eval 19) line 1.
Can't locate package Encode::Encoding for @Encode::utf8::ISA at (eval
19) line 1.
	(in cleanup) Can't locate object method "renewed" via package
"Encode::utf8" (perhaps you forgot to load "Encode::utf8"?) at (eval 19)
line 1.
	(in cleanup) Can't locate object method "renewed" via package
"Encode::utf8" (perhaps you forgot to load "Encode::utf8"?) at (eval 19)
line 1.

What can be done to make the 2nd case behave like the first?
--
Ron Savage
ro...@sa...
http://savage.net.au/index.html

Re: [Cgi-session-user] JSON problems as per RT bug 25325

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

Ron Savage wrote:
> Hi Mark
> 
> (1) JSON
> 
> I replaced JSON::Syck with JSON::XS to see what would happen, but the
> test program t/g4_dbfile_json.t still dies horriby, but differently.
> 
> JSON::Any just tries to load JSON modules one at a time, so it would
> stumble across either of the above 2 if they were installed. So it
> offers no advantage.
> 
> A patch will remove JSON from the docs, tests, and serializers.

Great. Thanks!

> (2) YAML
> 
> I do not get the error reported:
> http://rt.cpan.org/Public/Bug/Display.html?id=18948.
> 
> My versions are:
> ron@zoe:~/perl.modules/Patched-4.20$ perl -MYAML -e 'print
> "$YAML::VERSION\n";'
> 0.66
> ron@zoe:~/perl.modules/Patched-4.20$ perl -MYAML::Syck -e 'print
> "$YAML::Syck::VERSION\n";'
> 1.04
> 
> So what's the policy? Do we let uses have installation failures until
> they upgrade, or do we chop YAML from the list of supported serializers?
> 
> I see a problem which chopping YAML (and JSON): People who upgrade to
> 4.21 (to be released with a dozen patches) and who are using YAML will
> lose support for YAML in order to gain the advantages of the patches.

I have used the YAML driver at least once myself and some interest in 
seeing it maintained.  I mind less that it is in the core.

The Makefile.PL could declare YAML as a feature. If you choose it, you 
get the latest versions of YAML.

Still, I could see how breaking it out as different distribution could 
be cleaner, and could still be an optional feature.

I don't think removing JSON or YAML in a future version would cause 
breakage for people who upgrade, because as far as I'm aware Perl 
installations don't delete files from previous versions, so the JSON and 
YAML drivers would remain on disk.  It would only become a problem on an 
upgrade via "clean install".

In sum, as long as you are working on it Ron it's fine with me to steer 
the solution towards your own inclinations, but I'm happy to be a 
sounding board if you are uncertain about what seems best.

       Mark

Re: [Cgi-session-user] RT#224 and CGI::Session::PureSQL

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

Ron Savage wrote:
> Hi Mark
> 
> Examining CGI::Session::PureSQL I see it starts with:
> use base qw(
>     CGI::Session
>     CGI::Session::ID::MD5
> 	CGI::Session::Serialize::SQLAbstract
> );
> but there is no package CGI::Session::ID::MD5, but there is a
> CGI::Session::ID::md5 (lc MD5). So, CGI::Session::PureSQL is not really
> production-ready, right :-)?

Hmm, I used it production.

> Also, I had to delete t/01_serialize_sql_abstract.t to make progress.
> 
> And what's this stuff about Indiana time? Even here in Australia we know
> there's no one dead or alive /really/ living in Indiana, right :-)))?

It turned out tests gave different results depending on what timezone 
they were run in, which was very frustrating to debug. (They passed for 
me, but not for some other people once they hit CPAN). If I had to 
revisit that again, I would try one of the newer Perl development 
modules that fake what the time is.

> Should I work on CGI::Session::PureSQL (hint: No) or should I pursue the
> idea of getting the DBI-oriented code to accept specific names for
> columns, not just for MySQL, but Pg, and (gasp) my own code:
> o CGI::Session::Driver::odbc
> o CGI::Session::Driver::oracle
> 
> I can see I might add $IdName and $DataName say alongside $TableName in
> CGI::Session::Driver::DBI and to have that package's descendents also
> have local vars of the same name and to default the values from the
> parent. That way, users could set the 2 col names the same way they can
> set the table name. What do you think?

First, it would be interesting to know that the module you found was for 
CGI::Session 3.x.

The 4.x version was eventually completed and published here:

http://search.cpan.org/~markstos/CGI-Session-Driver-pure_sql-0.62/lib/CGI/Session/Driver/pure_sql.pm

Because the SQL it uses is very simple, it is likely to already work 
with several DB backends.

    Mark

[Cgi-session-user] RT#224 and CGI::Session::PureSQL

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

Hi Mark

Examining CGI::Session::PureSQL I see it starts with:
use base qw(
    CGI::Session
    CGI::Session::ID::MD5
	CGI::Session::Serialize::SQLAbstract
);
but there is no package CGI::Session::ID::MD5, but there is a
CGI::Session::ID::md5 (lc MD5). So, CGI::Session::PureSQL is not really
production-ready, right :-)?

Also, I had to delete t/01_serialize_sql_abstract.t to make progress.

And what's this stuff about Indiana time? Even here in Australia we know
there's no one dead or alive /really/ living in Indiana, right :-)))?

Should I work on CGI::Session::PureSQL (hint: No) or should I pursue the
idea of getting the DBI-oriented code to accept specific names for
columns, not just for MySQL, but Pg, and (gasp) my own code:
o CGI::Session::Driver::odbc
o CGI::Session::Driver::oracle

I can see I might add $IdName and $DataName say alongside $TableName in
CGI::Session::Driver::DBI and to have that package's descendents also
have local vars of the same name and to default the values from the
parent. That way, users could set the 2 col names the same way they can
set the table name. What do you think?
-- 
Ron Savage
ro...@sa...
http://savage.net.au/index.html

Re: [Cgi-session-user] JSON problems as per RT bug 25325

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

Hi Mark

On Fri, 2008-03-07 at 09:48 -0500, Mark Stosberg wrote:
> Ron Savage wrote:
> > Hi Folks
> > 
> > I don't have any experience with JSON.
> > 
> > Is replacing JSON::Syck with JSON::Any practical?
> 
> My view is that if no one wants to step up to maintain this in the core, 
> it doesn't belong there if it is causing a problem (which it is), and no 
> one has stepped up for months.
> 
> It's time to eject it. It will function just as well as an external 
> distribution for those who wish to use it.

OK. I take you to mean wipe out all trace of JSON. Is that right?

> Jason Crome recently brought the SVN repo back online, so we should be 
> able to proceed with a release soon to follow through on that goal.

OK.
-- 
Ron Savage
ro...@sa...
http://savage.net.au/index.html

Re: [Cgi-session-user] Utf8 problems as per RT bugs 28516 and 21981

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

Ron Savage wrote:
> Hi Folks
> 
> The new test program I've written passes all tests, but still emits a
> deliberate warning message. Here's my thinking:
> 
> o Tests and installation should not fail in all those cases people are
> not using utf8
> 
> o References to utf8 are on RT, the docs (with my patch), and this email
> list's archive, to help people diagnose problems
> 
> o My new test program passes all tests so automated testing and
> installation can continue, assuming all other problems are fixed, of
> course
> 
> o The new test emits a warning so anyone watching the tests' progress
> will see a reference to utf8 being problematic
> 
> o Clearly I do not have a solution to this problem, but I have no
> intention of diving into the innards of utf8-related code, so I see the
> new test as simply giving people more warning about utf8 problems than
> they've had up to now

This works for me as an immediate solution. Thanks for your work on 
this, Ron.

    Mark

Re: [Cgi-session-user] JSON problems as per RT bug 25325

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

Ron Savage wrote:
> Hi Folks
> 
> I don't have any experience with JSON.
> 
> Is replacing JSON::Syck with JSON::Any practical?

My view is that if no one wants to step up to maintain this in the core, 
it doesn't belong there if it is causing a problem (which it is), and no 
one has stepped up for months.

It's time to eject it. It will function just as well as an external 
distribution for those who wish to use it.

Jason Crome recently brought the SVN repo back online, so we should be 
able to proceed with a release soon to follow through on that goal.

    Mark

[Cgi-session-user] Utf8 problems as per RT bugs 28516 and 21981

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

Hi Folks

The new test program I've written passes all tests, but still emits a
deliberate warning message. Here's my thinking:

o Tests and installation should not fail in all those cases people are
not using utf8

o References to utf8 are on RT, the docs (with my patch), and this email
list's archive, to help people diagnose problems

o My new test program passes all tests so automated testing and
installation can continue, assuming all other problems are fixed, of
course

o The new test emits a warning so anyone watching the tests' progress
will see a reference to utf8 being problematic

o Clearly I do not have a solution to this problem, but I have no
intention of diving into the innards of utf8-related code, so I see the
new test as simply giving people more warning about utf8 problems than
they've had up to now

o All suggestions welcome
-- 
Ron Savage
ro...@sa...
http://savage.net.au/index.html

[Cgi-session-user] JSON problems as per RT bug 25325

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

Hi Folks

I don't have any experience with JSON.

Is replacing JSON::Syck with JSON::Any practical?

All suggestions welcome.
-- 
Ron Savage
ro...@sa...
http://savage.net.au/index.html