Molly and the Apache API

[Alexei Kosut <ak...@nueva.pvt.k12.ca.us>]

Hi. I wrote this as a part of a response to Rasmus' mail. Then I
realized it had nothing to do with regex libraries, so I split it off
and am mailing it separately. Feel free to ignore it; it's 12:21 in
the morning so for all I know it's 80 lines of pure drivel. Or maybe I
have something interesting to say :)

I had a thought about the Apache API the other day: It's
undocumented. I don't mean that in the sense that it's not specified
how to program using it. I mean, the Apache Group doesn't really have
up-to-date formal docs on it, but you can figure it out pretty easily,
and Ben's book does a good job. What I mean is that nowhere is there a
list of all the functions and structures and things that are
considered part of the API, and their definition.

This would be good to have (or at least to maintain for the Apache 2.0
API - which, by the way, I fully anticipate will break all existing
Apache modules and things), for one reason that came to me suddenly:
So people can clone our API. There are a couple of servers not made by
Netscape that implement the NSAPI. There are dozens of servers not
made by Microsoft that implement the ISAPI. In fact, there have been
modules written for Apache that do both. Every Mac web server sold
implements the WebSTAR API. But I'm not aware of a single web server
that implements the Apache API except for ours.

Yet it's the most common. Why is this? Probably two reasons. One is
that no one can figure the darn API out, at least not to the level
needed to replicate it. This needn't be the case; the Apache API does
not do all that much that couldn't be reasonably emulated by another
server, it just does it in mysterious and undocumented ways; it's
easier to port a module from the Apache API to NSAPI or ISAPI than
write an envelope library. So when we do 2.0, I think we should be
considerate of this issue.

The other reason, which isn't related to what I've just said but also
relates to 2.0, is that Apache does not really have a good (built-in)
dynamic loading facility for modules. It's a pain to add modules to
Apache: You have to recompile the server, even if the module you're
adding is precompiled. So it's easier to distribute modules as
source. Which means that not many people sell Apache modules. Or write
them for wide distribution in a commercial sense. Which means that
there's no reason for a server to implement the Apache API.

Let's look at another example. I mentioned WebSTAR earlier. The more
recent versions of this Mac server have an API, and allow
"plug-ins". Although I have not examined the API exactly, I think it's
at least superficially similar to the Apache API and NSAPI and others
(you know what I mean). But it's easy to add these plug-ins. You
download them off the Net, or buy them on a floppy. You drag them into
a folder. You enable them in the config utility. Just like, for
example, a plug-in for Netscape Navigator. So there are logs of
WebSTAR plug-ins out there. People write them and share. People make
lots of money selling them. They occupy a similar position as CGIs:
obtain, install, use. So almost all the Mac web servers out there
support WebSTAR plug-ins. Because it's a useful feature to have.

Apache doesn't have that. Apache needs to be able to figure out how to
make it easy to load modules. Have a "modules" directory that the user
can drop a module in, add a "LoadModule mod_foo" to httpd.conf, restart
their server and go. And it should work on all systems, out of the
Apache box. Probably we should add a built-in mechanism for accessing
the Apache API natively from Perl and Java, so you can load modules
that are cross-platform.

If we do this, then we create an instant marketplace, for people to
create "Apache plug-ins" and deseminate them. Admittedly, there are a
few of these now. mod_php. mod_perl. Stuff like that. But making easy
plug-in-ability would open it up to the commercial field as
well. Wouldn't it be neat to open up a mail order catalog and see a
page full of Apache plug-ins?

And, to get back to the point of this message, it would inspire people
to emulate the Apache API. So we'd better have an API worth
cloning. Or one able to be...


-- 
________________________________________________________________________
Alexei Kosut <ak...@nueva.pvt.k12.ca.us>      The Apache HTTP Server
URL: http://www.nueva.pvt.k12.ca.us/~akosut/   http://www.apache.org/


-- 
________________________________________________________________________
Alexei Kosut <ak...@nueva.pvt.k12.ca.us>      The Apache HTTP Server
URL: http://www.nueva.pvt.k12.ca.us/~akosut/   http://www.apache.org/

Re: Molly and the Apache API

[Rasmus Lerdorf <ra...@lerdorf.on.ca>]

> The other reason, which isn't related to what I've just said but also
> relates to 2.0, is that Apache does not really have a good (built-in)
> dynamic loading facility for modules. It's a pain to add modules to
> Apache: You have to recompile the server, even if the module you're
> adding is precompiled. So it's easier to distribute modules as
> source. Which means that not many people sell Apache modules. Or write
> them for wide distribution in a commercial sense. Which means that
> there's no reason for a server to implement the Apache API.

I have played a bit with mod_dld and mod_php together.  It does work, and
mod_php has an option in its install to configure it to be dynamically
loaded.  This doesn't really make it any easier to install the module, nor
does it have any real performance gains due to the pre-forking nature of
Apache, but it does have some level of nifty-coolness.

Along with a well-documented API, the other idea which has been floating
around here for a while of being able to extend the API through modules
would be a very good thing for 2.0.  Stuff like: mod_msql, mod_mysql,
mod_postgres, mod_ldap, mod_snmp, mod_anydbm, mod_odbc, mod_oracle, etc..
Being able to provide base-support for common things that multiple modules
might need would be a very good thing.  The current regex confusion would
be easily solved with a mod_regex.  Not only does it give module writers a
common consistent interface for each of these, but it also gives us some
level of control of how these external library functions are called.  This
is probably going to be essential when we move to an MT environment.  A
lot of these libraries are not MT-Safe and probably never will be.  We
will have to ensure that only 1 thread at a time enters the library and if
we have 2 separate modules both using the same library directly, we would
have no way of controlling access.  If there was a common access point, we
could, or there would have to be some generic API mechanism whereby
modules would register the fact that they have entered a certain library
and then when they are done they would tell the API mechanism that they
are done.  Holy deadlock problems batman!

The one thing I can't quite figure out is how mod_perl issues could be
solved.  When you write a mod_perl script that does a "Use DBI" at the
beginning for example, and that loads say a MySQL and an Oracle layer,
these are probably not going to be able to make use of any sort of Apache
API abstraction of the respective libraries.  Same goes for the current
regex problem.  Sticking an apache_regexec() function in the API is
probably not going to make anybody run out and rewrite Perl to use these
functions.

-Rasmus