Re: Freeing cyclic refferences

2000-12-20 Thread Darren Duncan

On Wed, 20 Dec 2000, Radovan Semancik wrote:
 I have perl objects with cyclic refferences to each othen in mod_perl
 environment. I know that these objects will never be freed unless I
 break the refference cycle. But, how to do it transparently for user of
 object?

What you need to do is to have a "starting" node in your
reference cycle that doesn't have anything pointing to it.  Such as the
"head" pointer of a linked list.  If the DESTROY method of this object
were to explicitely call some clean-up method of yours that is in the
regular node objects (clearing internode references), then the whole
process should be transparent to the user because all they have to do is
remove any references to the starting node, and they all vanish.  If your
entire set of linked objects is encapsulated in another one, then that
would effectively be your "start".

// Darren Duncan




Re: slight mod_perl problem

2000-12-20 Thread Darren Duncan

On Wed, 20 Dec 2000, Jamie Krasnoo wrote:
 Ok, it seems that my startup.pl is being run twice on server start.

Since configuration scripts can include other scripts, you probably have
more than one other script that includes startup.pl, or more than one
script that includes something that includes startup.pl, or other such.
This is a commonly encountered situation in programming.

What you need to do is scan your other relevant config files to look for
multiple includes of another file and remove one.  Or, if this isn't
feasible, then there may be some conditional that you can use to check if
you already ran a script, and then not do it again.

Of course, there could be a different reason that this is happening...

// Darren Duncan






Re: HTTP authentication based sessioning with logout ability

2000-12-19 Thread Darren Duncan

I have also been doing problem solving related to session handling and I
will briefly share my ideas for a solution.  What I am about to say is
just the logic or protocol behind my solution without getting into
implementation details.  I don't know if it'll help you, but here goes:

Essentially I had a server-side data store that tracked 4 pieces of
information on a client session for authentication purposes:
1. session code or login name (primary key)
2. the "realm"/cookie that the client got on the last log in
3. the date and time of their last log in or request
4. the IP address (or something) of the client machine when last logged in

The above information is checked each time the client makes a request.  If
any is not acceptible then they are prompted for their user id and
password again.  "acceptible" means that the realm and IP are the same as
before, and that less than a certain amount of time passed since they were
prompted for a password.  If users log out then the "realm" is reset to
nil so that they would have to be prompted on a log-in later.

HTTP authentication can be used to gather the login name and password, or
an html form could be used (greater compatability).  It doesn't
really matter.

The back-end data store also remembered the cumulative effect of whatever
users did during the session, so it doesn't all need to be passed back and
forth by the browser.  So if the web browser crashes or they move to
another computer or their session times out, all they have to do is
answer the new prompt for a username/password and they can continue right
where they left off.  This also means that their short-term workflow is
remembered, so they have the same screen they left with.  The actual
commitment of their changes is only done at certain times, such as when
they request to save changes.  Meanwhile, the actual back-end data isn't
left in a volatile state.

I think that my solution has advantages of convenience, security, data
integrity, compatability and so forth.  Also, web browsers have very
little that they need to remember.  The catch is that users need to have
login ids and passwords, and that their activity is tracked by the server
(at least short term).  But my solution was designed for users who were
registered and approved to edit the database, not anonymous individuals.
Although, this methodology could still be adapted for anonymous uses...

FYI: My requirements were to facilitate a web-accessible resource that
could be edited by multiple registered people at once, and as such, each person
would have their own login name and password.  Fairly standard so far,
right?  But in addition to that, it needed to let them do their work at a
public station or office where the same user could be sitting at several
different computers in one day, and several people could use the same
computer.  Additionally, an editing task could be either simple or quite
involved, meaning that the user may have to abandon their session and
continue where they left off later.  I needed precautions against the
browser crashing or it being left open after the user leaves for others to
see.  Finally, the edited information would be hierarchical, often
requiring multiple screens, as well as going up a path and then returning,
with what they did up the path being remembered.  The same user may even
want to edit several unrelated pieces of information at once, doing first
one, then stopping and doing something else, and then returning to what
they were doing before.

Now, I don't know if any of this has helped you or not, but it certainly
has helped me.

Good days,

// Darren Duncan






Document contains no data

2000-12-19 Thread Darren Duncan

I have been having a problem with my scripts during the where I 
periodically get a Netscape 4 error saying "Document contains no 
data" when they run under mod_perl, but not with the same script 
under CGI.  And this only happens sometimes; other times the pages 
return fine.  However, the problem happens very often, even while not 
all the time.  At some points it happens many times sequentially.

The problems started soon after I switched to mod_perl on my server 
using this in the .htaccess file (files named .cgi run as CGI):

Files *.pl
SetHandler perl-script
PerlHandler Apache::Registry
Options +ExecCGI
/Files

I did a search in the Guide for this error and otherwise looked in 
the troubleshooting sections, but could find nothing.

So I am hoping that you all can forgive me for asking help on this problem.

Everything else is working fine as near as I can tell.

I do not use any global variables explicitely, so I don't see how 
there could be persistant variable issues.  I also print my entire 
output with headers in a single print statement.

I am printing the "HTTP/1.0 200 OK\r\n" ahead of the other headers 
when running under mod_perl as I am supposed to.  And when pages do 
display they show evidence of this (no extra header text appears).

I believe that my mod_perl set-up has about 10 child processes in it, 
and site traffic is on the order of about 300-1000 hits per day.

Stop/Starting the server did not make a difference.  Non perl files 
still are served fine so far and so are .cgi files.

Help?

// Darren Duncan



Re: greetings and questions

2000-12-14 Thread Darren Duncan

Thanks to everyone who answered my questions in some form or other.

As it is, I *had* been reading whatever manuals I found, but those 
were the documentation that came with the mod_perl distribution on 
CPAN.

I was not aware of the existence of "http://perl.apache.org/guide/" 
and if I had been then I would have looked there.  I had seen a 
number of documents on the perl.apache.org server, but not that one. 
So thanks to those of you who pointed it out.

And no, I'm not offended by any "RTFM" comments.  I can fully 
understand that many of you would have seen the same questions asked 
over and over by people that didn't read the FAQs first.  So while I 
had read some FAQs it seems like I missed the important one.  Chalk 
it up to my first posting on a new listserv.

So I will look at The Guide now.

Thank you,

// Darren Duncan

P.S. Tom Brown, what a small world this is?