perl-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Doug MacEachern <>
Subject Re: 2.0 paper
Date Thu, 14 Sep 2000 18:33:03 GMT
On Thu, 14 Sep 2000, David Leeson wrote:

> We don't have cold beer in the UK. Especially in London: its warm and
> flat and (being a Northerner) , doesn't have a head (of froth...) ;-(

oh well, so long as there's some sort of beer :)
> This is great stuff, especially proper thread support.
> One problem I come up against all the time (and the style suggested
> in the mod_perl guide and the Apache::TicketAccess module) is that
> of configuration parameters for the server or virtual host. That is things
> that may be common to the whole app system (i.e. DSN configurations for
> the Apache::DBI), per-app configurations (i.e. file locations or specific
> database UID/PWD connections), and on-the-fly configs passed from one handler
> to the next. Up to now a kind of global/my assoc array has been used
> that is created by and is a coarse solution. 

have you looked at using directive handlers for configuration?

> With threading,
> I think we will have additional needs to add semaphores for changing
> values, and more fine-grained resolution to control which app sees
> which configuration.
> In CORBA the Property service goes someway to this. Will Apache 2.0
> have a configuration parameter look-up facility with controlled modification
> (i.e. through locks/semaphores)?

something rigged up around libmm should be able to provide this.
> In addition, I think the commonly used Apache objects (i.e. Apache::Request
> Apache::URI, Apache::Cookie, Apache::CGI) may be better done as
> standard services and the dynamic (or 'C') part of the code actually
> be built in to the distribution. The mistake C++ made for ages was not
> having a Universal library for commonly used components, and so it
> took ages before a standard (even if proprietary) form of linked lists
> and hash trees and other collections took hold. Now of course ANSI C++
> has the standard library, and I think Apache mod_perl would benefit from 
> having a similar thing (which is reviewed every so often to allow other
> commonly used modules to be added/enhanced/rewritten).

that will probably happen.
> Another nice idea (at least I think so) would maybe to incorporate
> an RPC mechanism so that mod_perl scripts could be accessed
> via other mechanisms other than HTTP/Apache protocol/interface.
> This would allow the web servers to become application servers with
> another technology/message protocol interface (i.e. HTTP and IIOP: 
> CORBA and RMI and others that I can't think of at the moment...).
> In this case I have had significant success with RPC::PlServer and
> RPC::PlClient (thanks Jochen) which has a nice O-O remote object
> access capability. Apache then could becomes a bit like an ORB.

indeed, i was thinking about writing a protocol handler for RPC::PlServer,
to take advange of the apache server framework (which should smoke the
Perl version performance wise), and leave the rpc marshalling to

View raw message