httpd-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Paul Richards <p.richa...@elsevier.co.uk>
Subject Re: get_client_block()
Date Mon, 04 Nov 1996 18:04:35 GMT
Alexei Kosut <akosut@nueva.pvt.k12.ca.us> writes:

> On Thu, 31 Oct 1996, Randy Terbush wrote:
> 
> > Did the name of this function absolutely have to change?
> > 
> > This is causing a great deal of confusion within mod_perl,
> > and I suspect this is only the beginning.
> 
> Yes, it did. Otherwise, modules that were designed for 1.0/1.1 would
> compile okay, but fail to work correctly, because the meaning of
> read/get_client_block has *completely* changed, and two new functions
> (setup_client_block and should_client_block) have been added, both of
> which are absolutely neccessary.

This should be handled by an API version bump not changing the name of
a previously used function just to stop old modules compiling, that's
nasty, you've just broken every existing module.

You should have created a completely new function with a different name
that 1.2 modules used if the interface had changed that radically.  We
need to implement an API version check *NOW* before this gets any worse
and we should maintain support for previous API versions or all those
third party modules are going to break.  The longer we leave this the
more legacy modules we'll have out there. If it's done now then we can
assume that anything that doesn't register itself as requiring API
version X will use API version 1. Once there are lots of different API
versions out there we'll have chaos.

-- 
  Paul Richards. Originative Solutions Ltd.  (Netcraft Ltd. contractor)
  Elsevier Science TIS online journal project.
  Email: p.richards@elsevier.co.uk
  Phone: 0370 462071 (Mobile), +44 (0)1865 843155

Mime
View raw message