Re: Apache Scripting Architecture

> 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 comments. 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) -Rasmus -- PHP Development Mailing List http://www.php.net/ To unsubscribe send an empty message to php-dev-unsubscribe@lists.php.net For help: php-dev-help@lists.php.net