Re: [Tzdist] tzdist examples

[Lester Caine <[e-mail]>]

On 12/01/15 13:44, Cyrus Daboo wrote:
>> I don't see any problem - as far as I am aware as long as the hash
>> returned via ETag for the same data package is the same for each server
>> then there is no problem
> 
> That may not happen. Remember that each server takes the raw publisher
> data and generates a representation in the media formats it servers up.
> For iCalendar, the generated data is not guaranteed to be byte-for-byte
> the same across all servers because different iCalendar libraries may
> generate data in slightly different ways, or generate different values
> for required properties like the product id.
> 
> We need to separate ETags (which represent a byte-for-byte state token
> for an HTTP resource) from the "semantic" state token - which in the
> case of tzdist is the tuple (publisher, version).
> 
> The (publisher, version) tuple is what clients use to sync across
> different servers - the ETag is what clients use to update from a server
> it already has data for. That is covered in the examples I sent out - in
> particular #3 which shows a client with existing data from one server,
> trying to sync with a different server. I believe that covers exactly
> what you are after.

That all makes perfect sense, and I can understand the problems with the
format of information being different. However it is my understanding
that the generation of a value for ETag need not be strictly locked to
the physical data. Weak validation is specifically defined as
semantically equivalent and NOT byte for byte matches. If the data
packet has a semantic difference there something is fundamentally wrong
with that source?

I'm not bothered about just what ETag is doing, as long as there is now
agreement that (publisher, version) is the basis for something that is
flexible enough to meet some peoples alternate requirements while
allowing all of the currently identified race conditions to be avoided.
At the present time, as long as a publisher follows the basic rules I
can't see any possible holes in the future, even if a completely new TZ
identification structure came into existence, so if ETag says 'no
change' or a request returns an empty packet until such time as there is
new information then I'm not too bothered. Ideally both should simply
work? I think the argument is if ETag should be the only mechanism?

-- 
Lester Caine - G8HFL
-----------------------------
Contact - http://lsces.co.uk/wiki/?page=contact
L.S.Caine Electronic Services - http://lsces.co.uk
EnquirySolve - http://enquirysolve.com/
Model Engineers Digital Workshop - http://medw.co.uk
Rainbow Digital Media - http://rainbowdigitalmedia.co.uk