httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Chuck Murcko <>
Subject Re: binary backwards compatability.
Date Fri, 31 Mar 2000 03:55:15 GMT
Manoj Kasichainula wrote:
> On Thu, Mar 30, 2000 at 01:58:37PM -0500, Ryan Bloom wrote:
> > ap_check_api("ap_foo", "argument string");
> > ap_check_struct("request_rec", sizeof(request_rec));
> > The argument string would be something like:
> >
> > "rr ct s i"
> And this doesn't feel painful to you? :) I guess it could be
> automated. But using a stable wrapper API just seems so much simpler.

At Platinum, we routinely did this. Once an API was defined, it *never*
changed the way it worked. Never. Only could be extended, not changed.
Same with public data structures, never rearranged, only padded. APIs
were kept completely opaque. While this clearly did not eliminate all
the headaches of OS changes underneath us, even with an APR-like layer
of code (esp. WinStuff) it made things possible to work across large (in
most cases major) release versions. We used shared libs only, so we
necessarily supported less platforms that Apache.

Greg's right. A module can have no knowledge of future server changes.
But the server can definitely be built to allow a wide range of module
versions to work, with sufficient care. To use the request_rec example,
no, you *never* obsolete it, although you may pad it with added members,
or internally use it differently as the server core changes, as an
intermediate store that gets internally converted to the new
representation(s). And you write the server to work with that limited
data if that's all that's available. Perhaps it then doesn't do the new
whizbang features of a newer module version, but it will work.

Of course, there's a price to pay. Lots of care with releases, lots of
testing, paying a lot of attention to picking a good API the first time,
to minimize headaches later. It's not impossible, just difficult. With
Apache, all that would have to start with 2.0.
Chuck Murcko
Topsail Group

View raw message