RE: [RFC] InodeEtag option

["Dietz, Phil E." <PE...@West.com>]

No one has replied.  Any opinions ?

> -----Original Message-----
> From:	William A. Rowe, Jr. [SMTP:wrowe@rowe-clan.net]
> Sent:	Monday, February 26, 2001 3:17 PM
> To:	new-httpd@apache.org
> Subject:	Re: [RFC] InodeEtag option
> 
> From: "Rodent of Unusual Size" <Ke...@Golux.Com>
> Sent: Monday, February 26, 2001 3:01 PM
> 
> 
> > "Dietz, Phil E." wrote:
> > > 
> > > - the allow_options_t size increased to a long because all 8 bits
> > > of char were in use.
> > 
> > Ouch.  I think that has killed changes to Options in the past.
> 
> So do we
> 
> 1. bite the bullet and increment the mmn?
> 
> 2. add more_options as a long at the end of the structure, increment
>    the mmn, and perhaps some authors get away with ignoring the bump?
> 
> Bill

Re: [RFC] InodeEtag option

["William A. Rowe, Jr." <ad...@rowe-clan.net>]

From: "Dietz, Phil E." <PE...@West.com>
Sent: Thursday, March 01, 2001 11:50 AM


> No one has replied.  Any opinions ?

Sorry, my own vote is #2.  It retains a higher degree of compatibility with old binaries


> > -----Original Message-----
> > From: William A. Rowe, Jr. [SMTP:wrowe@rowe-clan.net]
> > Sent: Monday, February 26, 2001 3:17 PM
> > To: new-httpd@apache.org
> > Subject: Re: [RFC] InodeEtag option
> > 
> > From: "Rodent of Unusual Size" <Ke...@Golux.Com>
> > Sent: Monday, February 26, 2001 3:01 PM
> > 
> > 
> > > "Dietz, Phil E." wrote:
> > > > 
> > > > - the allow_options_t size increased to a long because all 8 bits
> > > > of char were in use.
> > > 
> > > Ouch.  I think that has killed changes to Options in the past.
> > 
> > So do we
> > 
> > 1. bite the bullet and increment the mmn?
> > 
> > 2. add more_options as a long at the end of the structure, increment
> >    the mmn, and perhaps some authors get away with ignoring the bump?
> > 
> > Bill
> 

RE: [RFC] InodeEtag option

[Marc Slemko <ma...@znep.com>]

On Thu, 1 Mar 2001, Joshua Slive wrote:

> 
> On Thu, 1 Mar 2001, Dietz, Phil E. wrote:
> 
> > No one has replied.  Any opinions ?
> >
> 
> I don't see why this is being implemented as an "Option".  What is the
> harm of adding another directive?  Problems with the "Option" approach:

Right.  I think this is the rationale behind all the objections to adding
more Options before; Options are a historical anachronism from before "the
server" (NCSA at the time) easily supported the more flexible config
language that Apache now supports.



> 
> 1. The options syntax is confusing overall.
> 
> 2. I still believe this implementation is contrary to the way that other
> Options work, although I have not looked at the code in detail.
> 
> Joshua.
> 

RE: [RFC] InodeEtag option

[Joshua Slive <sl...@finance.commerce.ubc.ca>]

On Thu, 1 Mar 2001, Dietz, Phil E. wrote:

> No one has replied.  Any opinions ?
>

I don't see why this is being implemented as an "Option".  What is the
harm of adding another directive?  Problems with the "Option" approach:

1. The options syntax is confusing overall.

2. I still believe this implementation is contrary to the way that other
Options work, although I have not looked at the code in detail.

Joshua.