Re: get_client_block()

[Alexei Kosut <ak...@nueva.pvt.k12.ca.us>]

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 is all needed to support HTTP/1.1. If there was another way to
have done it, I would have. But there wasn't. I've written a more
detailed explanation of why the changes were made; you can look
through the new-httpd archives for them

http://dev.apache.org/httpd/mail/

-- 
________________________________________________________________________
Alexei Kosut <ak...@nueva.pvt.k12.ca.us>      The Apache HTTP Server
URL: http://www.nueva.pvt.k12.ca.us/~akosut/   http://www.apache.org/

Re: get_client_block()

[Alexei Kosut <ak...@nueva.pvt.k12.ca.us>]

On 4 Nov 1996, Paul Richards wrote:

> 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.

Yes. They would be broken otherwise. They would not work correctly
with the new setup. The API number has bumeen bumped, but that doesn't
affect modules that are *recompiled* under the new server (and since
dld works... well... not at all... that's what everyone has to do).

> 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

Um... I did. Isn't that what I just said?

> need to implement an API version check *NOW* before this gets any worse

There is an API version check. But it only affects pre-compiled object
files, not things that are compiled newly. This is why the function
name had to change - because it does something completely differnet.

> 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.

This is something that's on the 2.0 to-do list. For 1.x, it's enough
to simply say that you need three different versions of the module
(1.0, 1,1 and 1.2 - 1.0 and 1.1 are probably the same anyhow) - and
you can use #if statements to control this transparently to the user,
because the API number has been bumped each time athe API has been
changed/enhanced (I've been very careful about this).

And it wasn't just a change for the sake of change or even for better
programming and capability - if we were back-compaible with old use of
the read_client_block() function in any way, Apache could not be
HTTP/1.1 compliant. At all. There is (unforunatley) no way around
this.

-- 
________________________________________________________________________
Alexei Kosut <ak...@nueva.pvt.k12.ca.us>      The Apache HTTP Server
URL: http://www.nueva.pvt.k12.ca.us/~akosut/   http://www.apache.org/

Re: get_client_block()

[Paul Richards <p....@elsevier.co.uk>]

Alexei Kosut <ak...@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