Re: Apache::Session::Object
Perrin- > modifying Apache::Session to support both interfaces and sending Jeffrey > the patch. This is a good suggestion. I'll try modifying Apache::Session first and sending Jeff the patch. If he doesn't want to integrate it I'll package it as a separate module. -Nate
Re: Apache::Session::Object
This is somewhat off the topic of your original post, but I have to admit
that I really am a tad alarmed at the interest in storing a credit card
number in a local session.
Usually CC numbers should at most either be emailed (PGPed) directly to the
customer without any temp file creation or passed through to a payment
gateway. That way there is no persistence of that sort of customer
information stored anywhere on the server.
At 04:50 PM 7/6/00 -0700, Nathan Wiger wrote:
>Perrin-
>
> > Is there a reason you can't use the OO interface that Apache::Session
> > comes with?
> >
> > $session->STORE('visa_number') = '7';
> > print $session->FETCH('visa_number');
> > $session->DELETE('visa_number');
>
>This isn't really a documented interface - it's an overloading of the
>tie methods so that the tied hash interface works. You can't find this
>by reading the manpage for Apache::Session, only by reading through the
>module itself or knowing enough about tie to know it's there.
>
> > If your module is using the tied interface to Apache::Session to do its
> > work, you're getting the worst of both worlds in terms of performance.
>
>Not sure quite what you mean, maybe you can clarify? Won't You always
>need to tie %session to Apache::Session:: to create the initial
>object, unless I'm missing something? Are you just referring to using
>FETCH, STORE, and DELETE directly inside the methods (i.e., rather than
>$session{'param'} use $session->FETCH('param') ?)
>
> > AUTOLOAD methods can be an additional slowdown if you don't cache
> > AUTOLOADed methods (i.e. if AUTOLOAD has to resolve the methods every
> > time).
>
>Good point.
>
> > I can see reasons for creating an OO module that subclasses
> > Apache::Session, but I would do it to add methods that don't map directly
> > to a single hash key.
>
>Exactly why I'm doing it:
>
>$session->visa_number(501);
>$session->visa_number;
>
>same function, but it maps to a combination of FETCH and STORE depending
>on the arguments.
>
>-Nate
__
Gunther Birznieks ([EMAIL PROTECTED])
eXtropia - The Web Technology Company
http://www.extropia.com/
Re: Apache::Session::Object
On Thu, 6 Jul 2000, Nathan Wiger wrote:
> > $session->STORE('visa_number') = '7';
> > print $session->FETCH('visa_number');
> > $session->DELETE('visa_number');
>
> This isn't really a documented interface - it's an overloading of the
> tie methods so that the tied hash interface works. You can't find this
> by reading the manpage for Apache::Session, only by reading through the
> module itself or knowing enough about tie to know it's there.
I guess I just figured most people knew that was how tie works. I suppose
it's not an officially supprted interface though.
> > If your module is using the tied interface to Apache::Session to do its
> > work, you're getting the worst of both worlds in terms of performance.
>
> Not sure quite what you mean, maybe you can clarify?
Using tie-d methods is slower than using normal methods, so if you have a
method that in turn calls a tie-d method, you're going to have significant
overhead versus just calling the STORE/FETCH methods directly.
> Won't You always need to tie %session to Apache::Session:: to
> create the initial object, unless I'm missing something?
You can call the TIEHASH method directly to get an object back.
> Are you just referring to using FETCH, STORE, and DELETE directly
> inside the methods (i.e., rather than $session{'param'} use
> $session->FETCH('param') ?)
That would certainly be faster.
> > I can see reasons for creating an OO module that subclasses
> > Apache::Session, but I would do it to add methods that don't map directly
> > to a single hash key.
>
> Exactly why I'm doing it:
>
>$session->visa_number(501);
>$session->visa_number;
>
> same function, but it maps to a combination of FETCH and STORE depending
> on the arguments.
I was thinking of a situation where calling the visa_number method also
sets 'validated' to 0 and 'card_type' to 'visa', or something like that.
Anyway, I don't want to discourage you from making an Apache::Session
subclass (it's another rite of passage that many a mod_perler has gone
through), but if all you want is method access to the functionality
already there I'd suggest either calling the TIE methods directly or
modifying Apache::Session to support both interfaces and sending Jeffrey
the patch. Otherwise you'll definitely be adding some performance
penalties that might limit the usefulness of your additions for people
with busy sites.
- Perrin
Re: Apache::Session::Object
Perrin-
> Is there a reason you can't use the OO interface that Apache::Session
> comes with?
>
> $session->STORE('visa_number') = '7';
> print $session->FETCH('visa_number');
> $session->DELETE('visa_number');
This isn't really a documented interface - it's an overloading of the
tie methods so that the tied hash interface works. You can't find this
by reading the manpage for Apache::Session, only by reading through the
module itself or knowing enough about tie to know it's there.
> If your module is using the tied interface to Apache::Session to do its
> work, you're getting the worst of both worlds in terms of performance.
Not sure quite what you mean, maybe you can clarify? Won't You always
need to tie %session to Apache::Session:: to create the initial
object, unless I'm missing something? Are you just referring to using
FETCH, STORE, and DELETE directly inside the methods (i.e., rather than
$session{'param'} use $session->FETCH('param') ?)
> AUTOLOAD methods can be an additional slowdown if you don't cache
> AUTOLOADed methods (i.e. if AUTOLOAD has to resolve the methods every
> time).
Good point.
> I can see reasons for creating an OO module that subclasses
> Apache::Session, but I would do it to add methods that don't map directly
> to a single hash key.
Exactly why I'm doing it:
$session->visa_number(501);
$session->visa_number;
same function, but it maps to a combination of FETCH and STORE depending
on the arguments.
-Nate
Re: Apache::Session::Object
On Thu, 6 Jul 2000, Nathan Wiger wrote:
> I've created an object interface to Apache::Session. It's a simple
> module that I've called Apache::Session::Object (seemed pretty
> intuitive) that presents the following interface:
>
># Create new session using the default File store
>use Apache::Session::Object;
>my $session = new Apache::Session::Object;
>
>my $id = $session->session_id; # get session_id
>$session->{visa_number} = "4441 2001 2039 1100";
>$session->param('visa_number') = "4441 2001 2039 1100"; # same
>
>
># Open existing session in the DB_File store
>use Apache::Session::Object;
>my $session2 = new Apache::Session::Object
> ($id, {Store => 'DB_File', Transaction => 1});
>
>print $session2->_session_id; # leading _ ok
>
># yet another way to skin the same cat
>$session->visa_number("4441 2001 2039 1100");
>print $session2->visa_number;
Is there a reason you can't use the OO interface that Apache::Session
comes with?
$session->STORE('visa_number') = '7';
print $session->FETCH('visa_number');
$session->DELETE('visa_number');
If your module is using the tied interface to Apache::Session to do its
work, you're getting the worst of both worlds in terms of performance.
AUTOLOAD methods can be an additional slowdown if you don't cache
AUTOLOADed methods (i.e. if AUTOLOAD has to resolve the methods every
time).
I can see reasons for creating an OO module that subclasses
Apache::Session, but I would do it to add methods that don't map directly
to a single hash key.
- Perrin
