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...) ;-(
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 startup.pl and is a coarse solution. 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)?
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).
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.
Just thoughts....
At 01:27 14/09/00 -0700, you wrote:
>my paper for apachecon still isn't done, mostly because each time i start
>to write about something new that doesn't exist yet, i got itchy and had
>to scratch it. there's some filtering and protocol handler stuff talked
>about that works, but i haven't checked in yet. most other things that
>don't work yet will probably happen too. again, it's an unfinished
>braindump, but hopefully some of the new ideas and stuff will be
>interesting:
>
> http://perl.apache.org/~dougm/modperl_2.0.html
>
>p.s.
>looking forward to cold beer in a london pub!
>
>
>---------------------------------------------------------------------
>To unsubscribe, e-mail: [EMAIL PROTECTED]
>For additional commands, e-mail: [EMAIL PROTECTED]
>
regards
-david
--------------------
Technical Director (CTO) mailto:[EMAIL PROTECTED]
Carvel Solutions Ltd. http://www.carvel.co.uk
Software, Internet & E-Commerce Solutions
Vindolanda, Abbeytown, Carlisle, Cumbria, CA7 4RG, UK.
Tel/Fax: +44 16973 61173
Mobile: +44 411 125307
"Never be afraid to try something new. Remember, amateurs built the Ark;
professionals built the Titanic."
---------------------------------------------------------------------
To unsubscribe, e-mail: [EMAIL PROTECTED]
For additional commands, e-mail: [EMAIL PROTECTED]
