On Mar 29, [EMAIL PROTECTED] hacked the bitstream to say...
modperl> Joshua> What you don't get here is interprocess communication
modperl> Joshua> which is what the use of $Application is geared for, that
modperl> Joshua> the data is stored is some process neutral location, so
modperl> Joshua> web requests may access the data independent of the httpd 
modperl> Joshua> process they are coming from.
modperl> Joshua> 
modperl> 
modperl> yes this is the killer with making my stuff work for both iis/asp & modperl.
modperl> do you have any suggestions for an api consistent solution? maybe i could
modperl> hack up something where $Application data was obtainable thru IPC? the
modperl> killer is the serialization requirement as i'm dealing with perl encapsulated
modperl> c++ objects... 

sorry to respond to myself but i just realized a got momentarily confused.
what i would love to have is

        api consistent (w/ IIS/ASP) means of all scripts served by apache
        process "foo" to be able to access the $Application data and that
        this data doesn't have a must-be-serializable requirement.

Apache::ASP currently provides

        $Application data thru MLDBM serialization that is available
        to ALL apache processes. 

i could imagine at least some people porting IIS/ASP/ActivePerlScript
applications to apache/mod_perl would appreciate someway to do what
i'm trying to do.

under IIS lots of folks make COM objects, stuff them in $Application
and all the IIS threads use the $App data just fine. when these folks
port to apache/linux use must drop COM (thus i'm wrapping straight C++
libraries into Perl objects with SWIG), but i still need this can't-require
serialization-support for $Application data requirement and would gladly
accept each process having its own $Application data.

what about a configuration option that was something like...
        
        PerlSetVar AppDataPerProcess (0|1)

jr

-- 
------------------------------------------------------------------------
Joel W. Reed                              http://ruby.ddiworld.com/jreed
----"This is a job for.. AACK! WAAUGHHH!! ...someone else." - Calvin----


Reply via email to