Re: Etag-on-write, 4rd attempt (== IETF draft 03), was: I-D ACTION:draft-reschke-http-etag-on-write-03.txt

On Nov 7, 2006, at 23:10, Wilfredo Sánchez Vega wrote:
>   It's not hard for a server to implement, but it's rather silly to  
> invalidate caches for all resources when it shouldn't be necessary.

I have no specific preference on this issue, but supporting two kinds  
of etags doesn't exactly reduce complexity in the HTTP stack and it  
might be worth dropping one of them (that is, only support strong  
etags).

Invalidated caches after software upgrades most likely won't be a  
major real world issue (how often do you actually change the  
generator). In fact I would tend to claim that implementing weak  
etags properly is very likely error prone (hard work to make the  
generator developer properly takes care of ensuring "ABI  
compatibility", much simpler/reliable to bump the version and drop  
the cache).

Greets,
   Helge

> 	-wsv
>
>
> On Nov 6, 2006, at 3:08 PM, Helge Hess wrote:
>
>> If the binary representation changes if the software changes, you  
>> "just" need to embed a software version identifier in the etag?  
>> (eg the iCal generation framework version [A/B/C...]) That doesn't  
>> sound too hard / inappropriate.

-- 
Helge Hess
http://docs.opengroupware.org/Members/helge/

Received on Tuesday, 7 November 2006 22:29:51 UTC