httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Manoj Kasichainula <man...@io.com>
Subject Re: cvs commit: apache-2.0/src/modules/standard mod_asis.c mod_autoindex.c mod_log_config.c mod_negotiation.c
Date Sat, 11 Sep 1999 06:30:29 GMT
On Sat, Sep 11, 1999 at 03:10:46PM +1000, Brian Havard wrote:
> On Fri, 10 Sep 1999 22:32:20 -0500, Manoj Kasichainula wrote:
> >1. The world is not an APRed world. At some point, Apache code has to
> >be able to interact with third-party code that doesn't use APR. To do
> >this, we have to have routines to convert back-and-forth
> 
> The problem is that different platforms use different types.

The conversion routines are designed to be used with
platform-dependent code such as 3rd-party modules. They should not be
used in platform-in Dependant code unless the author is feeling
masochistic that day.

> Unix may always
> use an int but OS/2 uses HFILE (an unsigned long) and Win32 uses HANDLE (a
> void *), neither of which will make any 3rd party libs happy as they use
> different 'handle space' to the unix style file descriptors.

Any 3rd party lib will use these types. APRed code has to be able to
access them. This can't be done without an interface to convert
between the two worlds.

Think of it this way. We want our Apache server w/ PHP to have
Oracle access. Apache uses APR and Oracle uses native OS interfaces.
PHP has to be able to talk to both Apache and the Oracle libs. In a
world without conversion routines, we're screwed. If PHP is written
to use APR, it can't pass file and socket handles, dates, etc. to the
Oracle libraries. If PHP uses the native interfaces, it can't talk to
Apache. There has to be an interface to jump between the two worlds
(sort of like the Java Native Interface).

Now, anyone who uses these conversion routines will have to accept the
fact that there will be "#ifdef PLATFORM"s thrown around a bit. APR
can't make platform differences disappear then, but it can help
minimize them.

> >2. The MPMs are examples of this. The MPMs will have platform-specific
> >code. The really cool ones will probably have really cool
> >platform-specific code. This code will have to interact with an APRed
> >core. So conversion between APR and native types will be necessary.
> 
> MPMs I guess are ok to use them but if they're fully platform specific then
> they may as well bypass APR altogether to do funky OS specific stuff.

As above, at some point, even a 100% platform-specific module has to
talk to Apache at some point, so we need a translator.

-- 
Manoj Kasichainula - manojk at io dot com - http://www.io.com/~manojk/
"When I think back to all the crap I learned in high school,
 it's a wonder I can think at all." -- Paul Simon

Mime
View raw message