httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Brian Pane <bp...@pacbell.net>
Subject Re: [PATCH] Turn apr_table_t into a hash table
Date Sun, 09 Sep 2001 00:28:27 GMT
Ian Holsman wrote:

> TOKILEY@aol.com wrote:
>
>> In a message dated 01-09-08 17:43:15 EDT, Ryan wrote...
>>
>>
>>> I know that there aren't many modules for 2.0 today, but at some
>>> point, everybody who has a module for 1.3 will want to port it to 
>>> 2.0.  I can currently do that in under one hour for even complex 
>>> modules.  Changing API's like this after we have had 25 releases, 
>>> makes that harder.
>>>
>>> Ryan
>>>
>>
>> It's a certainty that when the general public has enough confidence
>> in 2.0 to start porting all the existing modules over ( mod_oas, 
>> mod_bandwidth, mod_my_module, God all what else ) they will
>> do so by using the 1.x.x code and just changing as little as
>> possible... which traps all the other API calls in there.
>>
>> It certainly would be best to be very careful about changing
>> any more API's at this point until 2.0 is out the door and
>> flying under its own power. It's almost ready.
>
>
>
> once 2.0 is out the door it is going to be hard/impossible
> to change ANY api, as you will break alot of people's work
> and people will have a hard time upgrading.
> If there is going to be a API change NOW is the time.
> Since the last beta there have been several API changes, and
> have caused 3rd party modules (like mod-proxy, and our internal ones)
> to fail. I expect this in a beta/alpha, not in a released product. 

I agree.  And in fact, if we were to change nothing else about
apr_table_t between now and 2.0 GA, I'd still want to replace
apr_table_elts with an abstract iterator API.  This would
enable us to guarantee to module authors that their code
wouldn't break in the future as the internals of apr_table_t
evolved.

--Brian




Mime
View raw message