ATTN Apache Developers: Apache 1.3.x and Binary compatibility

ATTN Apache Developers: Apache 1.3.x and Binary compatibility

Post by Tom Jordah » Sat, 27 Mar 1999 04:00:00



Hello,

My company makes ColdFusion, which has a web server component,
written in C++, that plugs in to various servers on Solaris, HPUX
Windows NT and Linux.

We ship a binary version of our module with our product for both
Apache 1.2.6 and Apache 1.3.  When Apache 1.3 was released, we
were e*d to learn of the Dynamic Module (DSO) support,
thinking it was created for just our situation:  Vendors who
for one reason or another ship a binary module that could be
plugged in to Apache without compilation by our customers.

Well, that is all well and good as long as the Apache developers
don't change the MODULE_MAGIC_NUMBER (see src/include/ap_mmn.h).

This number has been changed so far in every 'minor' release but one.
(Apache 1.3.3).  This has caused Allaire (and me) no end of customer
support and development headache.  Before the announcement of Apache
1.3.6 was even in my mailbox, technical support was talking to a
customer trying to use 1.3.6 with our module and having it fail.
This is particularly troubling on Windows NT, as generally those
customers DO NOT compile the server themselves, nor do they know
anything about it.

I know that most modules are shipped in source form and that most
people who install Apache compile it themselves.  Since our module
is written in C++ and uses code which we are not willing to release,
we currently ship in binary form.

This is a plea to the Apache developers to STOP changing the
interface.  You ARE affecting customers with these changes.
Please think very carefully if you go to touch ap_mmn.h that
you will be causing a great deal of hassle for at least one
company (Allaire) which is trying to fully support this great
web server.

Another smaller plea to those who write modules which change
the size or add fields to the request structure (i.e. mod_ssl).  
This is BAD. Binary modules will not work if you do this.  
Please don't.

Thanks for your attention.
Please CC me via Email on any replies.

--
Tom Jordahl                     tomj at allaire.com
Allaire Development             http://www.veryComputer.com/

 
 
 

ATTN Apache Developers: Apache 1.3.x and Binary compatibility

Post by Paul Rub » Sat, 27 Mar 1999 04:00:00




Quote:>This is a plea to the Apache developers to STOP changing the
>interface.  You ARE affecting customers with these changes.
>Please think very carefully if you go to touch ap_mmn.h that
>you will be causing a great deal of hassle for at least one
>company (Allaire) which is trying to fully support this great
>web server.

I urge the Apache developers to do whatever is best for open source
users.  If vendors of binary-only products get some benefit too,
that's ok, but please don't do anything that inconveniences source
users for the sake of supporting binary-only plug-ins.

Also, the idea that a binary-only product is trying to "fully support"
Apache is absurd, as is the notion that such a vendor is the Apache
developers' "customer" or is "fully supporting" Apache.  Fully
supporting Apache means shipping source for free.  Admittedly, not
everyone is in a position to do that, and that's ok, but don't
pretend to be doing something that you're not.

Quote:>Another smaller plea to those who write modules which change
>the size or add fields to the request structure (i.e. mod_ssl).  
>This is BAD. Binary modules will not work if you do this.  
>Please don't.

If there's a clean way for things like mod_ssl to avoid changing the
size, then that's fine; but if not, I'd say developers of binary
modules should just figure out a way to deal with the situation.

 
 
 

ATTN Apache Developers: Apache 1.3.x and Binary compatibility

Post by Rasmus Lerdo » Sat, 27 Mar 1999 04:00:00


Quote:> I know that most modules are shipped in source form and that most
> people who install Apache compile it themselves.  Since our module
> is written in C++ and uses code which we are not willing to release,
> we currently ship in binary form.

> This is a plea to the Apache developers to STOP changing the
> interface.  You ARE affecting customers with these changes.
> Please think very carefully if you go to touch ap_mmn.h that
> you will be causing a great deal of hassle for at least one
> company (Allaire) which is trying to fully support this great
> web server.

Feel free to submit a binary compatibility layer that will insulate you
from these problems.  With a market cap of over a half billion dollars,
perhaps a few Allaire resources could be set aside to help out with
Apache development?  Moaning about it in a public forum like this is not
going to get you very much sympathy.  And, I am not sure where you got
the idea that just because Apache 1.3.x supports dynamically loaded
modules that this would mean that the Apache internals would suddenly
never change.  No such claim was made and Apache internals are going to
continue to change.  Live with it, or come up with a proposal for solving
it.  

-Rasmus

 
 
 

ATTN Apache Developers: Apache 1.3.x and Binary compatibility

Post by Tom Jordah » Sat, 27 Mar 1999 04:00:00



> Feel free to submit a binary compatibility layer that will insulate you
> from these problems.  With a market cap of over a half billion dollars,
> perhaps a few Allaire resources could be set aside to help out with
> Apache development?  Moaning about it in a public forum like this is not
> going to get you very much sympathy.  

Hey, look.  Allaire is just trying to use the facilities that
the Apache group saw fit to include in the package.  There is no
point in getting hostile and flaming me about it.  And our
market cap has nothing to do with our available resources.

Quote:> And, I am not sure where you got
> the idea that just because Apache 1.3.x supports dynamically loaded
> modules that this would mean that the Apache internals would suddenly
> never change.  No such claim was made and Apache internals are going to
> continue to change.  Live with it, or come up with a proposal
> for solving it.

I didn't "get the idea that the internals would never change".
I got the idea that since they added an API version number,
they would exercise due consideration if/when they bumped it up,
breaking existing modules.  

The Apache group has ALREADY solved the problem.  They invented
the version number to prevent binary modules from being loaded
in to a server which has incompatible changes.

I just see no indication that the developers
who are changing the API version number realize they are affecting
module maintainers like myself.

--
Tom Jordahl                     tomj at allaire.com
Allaire Corp.                   http://www.allaire.com

 
 
 

ATTN Apache Developers: Apache 1.3.x and Binary compatibility

Post by Tom Jordah » Sat, 27 Mar 1999 04:00:00



> Also, the idea that a binary-only product is trying to "fully support"
> Apache is absurd, as is the notion that such a vendor is the Apache
> developers' "customer" or is "fully supporting" Apache.  

The 'customer' I was referring to was of course, the end user.
Not us.

Quote:> Fully
> supporting Apache means shipping source for free.  Admittedly, not
> everyone is in a position to do that, and that's ok, but don't
> pretend to be doing something that you're not.

I disagree with this 100%.  Supporting Apache and shipping source
have nothing to do with each other. I am not misrepresenting what
Allaire is doing.  We support Allaire customers who choose to run the
Apache web server on Windows or Unix.  In doing this, we support
the Apache web server.  Just like IBM and Apple support it by
including it with their OS offerings.

What good would it do to give our C++ source away to people who
would be unable to build it, much less configure it in to Apache?

--

Allaire Corp.                   http://www.allaire.com

 
 
 

ATTN Apache Developers: Apache 1.3.x and Binary compatibility

Post by Rasmus Lerdo » Sun, 28 Mar 1999 04:00:00


Quote:> I didn't "get the idea that the internals would never change".
> I got the idea that since they added an API version number,
> they would exercise due consideration if/when they bumped it up,
> breaking existing modules.  

> The Apache group has ALREADY solved the problem.  They invented
> the version number to prevent binary modules from being loaded
> in to a server which has incompatible changes.

> I just see no indication that the developers
> who are changing the API version number realize they are affecting
> module maintainers like myself.

Of course we do.  You think we just randomly change stuff?  Each change
had a valid and well thought-out reason behind it.  That doesn't change
the fact that no claim was ever made that there would be binary
compatibility for modules between any two versions of Apache.  The
version number is simply a safeguard to prevent modules built against a
different api from being loaded.  It is not any sort of binary
compatibility solution.  Occasionally you get lucky and two versions of
Apache do not have any low-level API changes that will affect your
module, but as you have discovered that has so far been the exception.

By the way, this discussion should be on the APache development list, and
not here.  And in fact it is.  You should go read what has been written
on this subject.

-Rasmus

 
 
 

ATTN Apache Developers: Apache 1.3.x and Binary compatibility

Post by Jonathan Baker-Bate » Sun, 28 Mar 1999 04:00:00


Quote:>Hey, look.  Allaire is just trying to use the facilities that
>the Apache group saw fit to include in the package.  There is no
>point in getting hostile and flaming me about it.

What did you expect? The open source community is hadly known for it's
accomodating attitude towards commercial software.

But I say don't worry about the tone of the replies - it's good that you're
bringing this into the arena. Collaborative free software development is
always teetering on the edge of anarchy at the best of times, and a little
nudge in the direction of commercial considerations and, in this case, the
promotion of the idea that perhaps not everyone who benefits from it should
also be expected to stay up all night recompling sources is a damn good
thing in my opinion.

JJ

 
 
 

ATTN Apache Developers: Apache 1.3.x and Binary compatibility

Post by Rasmus Lerdo » Mon, 29 Mar 1999 04:00:00



>>Hey, look.  Allaire is just trying to use the facilities that
>>the Apache group saw fit to include in the package.  There is no
>>point in getting hostile and flaming me about it.

>What did you expect? The open source community is hadly known for it's
>accomodating attitude towards commercial software.

I don't see any flames in the replies so far.  He thought I flamed him, I
guess, but it certainly wasn't intended as such.  

But, there were some irritated undertones, I guess.  This attitude of,

  "We are doing the world a huge favour by supporting the lowly Apache server
   by letting people purchase our software and now you go ahead and change
   things on a whim without any consideration for us"

does sort of irk some of us.  Things aren't changed on a whim, things are
changed and improved for the greater good of the entire community.  Yes,
changing the binary compatibility from one version to the next is annoying,
but the improvements some of these changes bring are also highly desirable.  
And some of them are actually to accomodate various commercial entities better.

-Rasmus

 
 
 

ATTN Apache Developers: Apache 1.3.x and Binary compatibility

Post by Marc Slemk » Tue, 30 Mar 1999 04:00:00



Quote:>I didn't "get the idea that the internals would never change".
>I got the idea that since they added an API version number,
>they would exercise due consideration if/when they bumped it up,
>breaking existing modules.  

And they do.  So what is the problem?

Unfortunately, just because an API change may not impact _your_ module
doesn't mean that the version number should remain the same since it
can impact other modules.

 
 
 

ATTN Apache Developers: Apache 1.3.x and Binary compatibility

Post by Ralf S. Engelschal » Tue, 30 Mar 1999 04:00:00



> [...] When Apache 1.3 was released, we
> were e*d to learn of the Dynamic Module (DSO) support,
> thinking it was created for just our situation:  Vendors who
> for one reason or another ship a binary module that could be
> plugged in to Apache without compilation by our customers.

No, the DSO support for Apache 1.3 wasn't introduced for this. You're thinking
is totally wrong here. The main goal was to achieve flexibility in building
Apache modules outside the Apache source tree but still from the module
source. Binary only modules were really not on the list of the DSO goals.

Quote:>[...]
> This is a plea to the Apache developers to STOP changing the
> interface.  You ARE affecting customers with these changes.

We know this but we always had good reasons to change the API.

Quote:>[...]
> Another smaller plea to those who write modules which change
> the size or add fields to the request structure (i.e. mod_ssl).
> This is BAD. Binary modules will not work if you do this.
> Please don't.

First, the EAPI changes of mod_ssl now _DO_ support loading of mod_coldfusion
even your module isn't compiled with EAPI. Second, the structures were not
changed just for fun. They _HAVE_ to be changed in order to support the SSL
layer. And it's no problem for modules distributed in source which can be
easily recompiled. So, when you don't want to release your module in source,
then please don't blame the Open Source community for this.

BTW, even when you don't want to release your C++ code I see no reason why you
can't distribute a mod_coldfusion.c in source which hides the Apache API and a
libcoldfusion.a in binary form which contains your actual Coldfusion stuff.
This way you solve all your problems, I think.

Greetings,
                                       Ralf S. Engelschall

                                       www.engelschall.com

 
 
 

ATTN Apache Developers: Apache 1.3.x and Binary compatibility

Post by Tom Jordah » Tue, 30 Mar 1999 04:00:00


Ralf,

Thanks for your post.


> No, the DSO support for Apache 1.3 wasn't introduced for this. You're thinking
> is totally wrong here. The main goal was to achieve flexibility in building
> Apache modules outside the Apache source tree but still from the module
> source. Binary only modules were really not on the list of the DSO goals.

OK, I guess I got the wrong idea here.  Originally I seem to remember
reading in the docs about distributing a binary module, but when I
look at the 1.3.6 docs, I find no such reference.

Quote:> We know this but we always had good reasons to change the API.

I am sure they were very good reasons.  I wanted to find a place
to publicize the fact that when you do make these changes, they
really *affect* someone.

Quote:> First, the EAPI changes of mod_ssl now _DO_ support loading of mod_coldfusion
> even your module isn't compiled with EAPI.

This is great news.  Our customers will be happy to hear this.
What versions of Apache and mod_ssl exactly will this work in?

Quote:> Second, the structures were not
> changed just for fun. They _HAVE_ to be changed in order to support the SSL
> layer.

I understand this.  Not having looked closely at the changes, I do
know that our simple module can withstand adding entries to the
end of the request structure no problem.  The only time our module
crashes is when software adds stuff to the *middle*, breaking our
precompiled code.  Or the API version number is changed, causing
apache to reject the module at startup.

Quote:>And it's no problem for modules distributed in source which can be
> easily recompiled. So, when you don't want to release your module in source,
> then please don't blame the Open Source community for this.

Again, I am not "blaming".  I was asking that the changes be thought
out more carefully.

Quote:> BTW, even when you don't want to release your C++ code I see no reason why you
> can't distribute a mod_coldfusion.c in source which hides the Apache API and a
> libcoldfusion.a in binary form which contains your actual Coldfusion stuff.
> This way you solve all your problems, I think.

This is in fact what we are doing for our Unix products.  And it
works.  This does NOT work out for Windows very well as most of
our customers load the pre compiled distribution and do not have
a compiler installed on their system.

--

Allaire Corp.                   http://www.allaire.com

 
 
 

ATTN Apache Developers: Apache 1.3.x and Binary compatibility

Post by Tom Jordah » Tue, 30 Mar 1999 04:00:00



> You think we just randomly change stuff?  Each change
> had a valid and well thought-out reason behind it.  

As a development engineer, I realize things change. I was hoping that
things wouldn't change in every minor point release.  

I was also assuming that the attitude might be: "well, everyone
releases a source version of their module, so it doesn't matter
that much when we rev the API version."  And, in fact, I have gotten
a bit of that feedback in response to my postings.  It is good to
know that the group realizes these changes have an effect.

Quote:> By the way, this discussion should be on the APache development list,
> and not here.  And in fact it is.  You should go read what has been
> written on this subject.

Rasmus,

Where can I get access to this list?  I perused the www.apache.org
site before I posted, looking for just such a list.

Thanks.

--

Allaire Corp.                   http://www.allaire.com

 
 
 

ATTN Apache Developers: Apache 1.3.x and Binary compatibility

Post by Rasmus Lerdor » Tue, 30 Mar 1999 04:00:00


Quote:> Where can I get access to this list?  I perused the www.apache.org
> site before I posted, looking for just such a list.

The information is here:

http://dev.apache.org/mailing-lists.html

-Rasmus

 
 
 

1. Attn: Apache Developers... Memory Leaks.

Hi,

I ran some tests on the Apache 1.3.3 source as a demo of a
memory checker program I'm evaluating.  I don't want to go into
any details here, but there were a few bugs (not many) having
to do with read- and write-overflows.  It seems to indicate
a problem with one of the alloc.c routines as well.

Since I couldn't seem to find a private email address to send
this to you, just email me at
        jacobs at bitstorm dot net
and ask for it.  It's a not-that-large textfile and I'll
send it to you (if I can confirm from somewhere that you
are actually one of the developers) *smile*.

I've been using this server since 0.8.something in Summer '95.
Thanks for some damn good software. :-)

        Regards,

        Stan

2. phrack - Java tears down the Firewall

3. Apache binary 1.3.x with EAPI for Solaris 2.6

4. x86 instalation problem

5. Solaris 2.6 x86 Apache 1.3 binary

6. Solaris 2.3 sendmail: $g macro in "From " line

7. binary mod_jk2 or mod_jk connector for Apache 1.3.x on Solaris 2.6 is needed.

8. support for NCR voyager

9. Apache 1.3 Binary RPM

10. Netscape 4.5 problem downloading binaries from site using apache 1.3

11. apache DSO problem (Loaded DSO libexec/mod_mime.so uses plain Apache 1.3 API)

12. newbie - apache 1.3 vs apache 2.0 questions

13. httpd.conf only since Apache 1.3.?