httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From "Thomas Reilly" <trei...@livesoftware.com>
Subject Re: am I dreaming?
Date Fri, 26 Mar 1999 01:01:45 GMT

"Roy T. Fielding" <fielding@kiwi.ics.uci.edu> writes:

> The ONLY way to provide binary compatibility across changes to the core
> data structures is to prevent access to those structures and place an
> intermediate translation module between the two.  In other words,
> mod_cgi, mod_perl, mod_php, mod_fastcgi, ...

Such a layer does us no good.  Let me clarify my situation.  Our
product is a servlet engine, in order for servlets to be executed the
request is captured by our module and sent to our servlet engine via a
socket based protocol.

We provide the source for this module but our users (particularly the
windows ones) love us to provide precompiled DSO's.  Sure compiling
the DSO with apxs is a one liner but a lot of systems don't have perl
and precompiled DSOs allow us to to have servlets run on Apache just
by installing our product and restarting apache.  A big win for the
non-hacker crowd.

When I first posted I was under the impression that these breaks in
binary compatibility could be avoided and were just oversights on the
part of the developers who understandably don't care too much about
binary compatibility.  However its since become clear to me that
normal healthy work on the server will break DSO compatability because
there is no clean separation from the Apache core and the module
architecture.

Until DSOs came about there was no need for such a separation.

Our module goes out of its way to not depend on Apache core.  We do
our own sockets calls and we don't make use of any preprocessor
symbols (except the STANDARD_STUFF in module which is causing all our
problems). 

Its understandable that Apache rejects our 1.3.4 module because it
might have made use of the METHODS and M_INVALID definitions.

I'm not sure how to deal with this.  There seems to be two options:

1) Add a new module architecture cleanly abstracted from Apache core
meant for use by DSOs

2) Make the current module architecture cleanly abstracted from Apache
   core

Number 2 is obviously more appealing but may not be possible depending
on how many core apache features the important modules need.  I think
such a clean change would be healthy for Apache and should maybe be
considered for a pre 2.0 change.  Is 1.3 the end of the 1.x line or is
1.4 a possibility?  I think its pretty clear that my dreams won't be
fulfilled in the 1.3 cycle.

In response to the comparison to linux modules I don't think that is a
fair one.  The beauty of DSOs is that you can add functionality to an
existing Apache server without rebuilding anything.  Linux modules are
primarily to combat the problem of the kernel size limitation.
Anyways I don't think you can distribute a proprietary linux kernel
module, I imagine these fall under the derivative works category and
must be GPL'd.

I apologize for the obscene length of this post.

--
Tom Reilly
Live Software, Inc
http://www.livesoftware.com

Mime
View raw message