httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Rasmus Lerdorf <>
Subject Re: Apache Scripting Architecture
Date Fri, 06 Nov 1998 18:43:32 GMT
> Apache <-API(A)-> Scripting Engine <-API(B)-> Script Interpreter
> mod_php, mod_perl, and mod_js already do everything.  IMHO a generic
> API(A) would be very useful for making it easy for newer scripting engines
> to plug into Apache.  Also, I'd love to see an API(B) from mod_php so that
> other scripting languages might be able to leverage the immense
> functionality already built into php.

We have some stuff in the works for PHP 3.1 where we want to completely
decouple the Web Server vs. Module API.  Our current 3.1 is working with
Apache API, NSAPI, ISAPI, and WSAPI, but it is pretty tightly coupled with
PHP. We have been writing some specs and ideas for completely abstracting
this layer and pulling it out as a standalone project.  I talked briefly
to OpenMarket and the mod_jserv guys at ApacheCon about this.  This would
fit into the API(A) role in your above diagram except I don't see why the
lefthand side should be limited to just Apache.  Make API(A) flexible
enough to allow any module written for that API to plug into any of the
supported web servers.  Wouldn't it be cool, for example, if Greg Stein's
mod_dav worked with IIS before M$ managed to add DAV support to IIS
themselves.  It would be nicely ironic considering their Halloween

Now, on the API(B) side things get tricky.  If you look into the guts of
something like Perl or PHP, it is not inherently obvious where the
division between the scripting engine and the interpreter is.  A clearly
defined API(B) would definitely be a cool thing to have, but you would
first need to define exactly what belongs on the engine side and what
belongs on the interpreter side.  In order for this to work, people who
are intimately familiar with Mozilla JS, PHP and Perl need to be involved
in creating this API.  I don't see how a single person can sit down and
define a useful API.  Sure, something can be written down and it may make
a lot of sense on paper, but I can pretty much guarantee that it won't fit
any realworld situations unless the person has done *a lot* of homework.

>From the PHP side, we are definitely willing to help.  When we get a
little further with our API(A) spec, we will definitely get that out and
solicit comments from everyone.  On the API(B) side it is a bit
overwhelming for me right now.  I can't wrap my head around the entire
problem yet.  I see where we need to be, but I don't quite see the first
step along the path to that point yet.

(This discussion should probably be moved to a more appropriate place)


View raw message