Re: [Tzdist] Fwd: [tzdist] #32 (service): managing historical data

[Lester Caine <[e-mail]>]

On 13/12/14 14:44, Cyrus Daboo wrote:

1 and 2 ... spot on ...

> 3) Open issue: does the version value belong in the time zone data
> returned by the server. My big concern about this is that I would prefer
> it if clients did not have to download an entire time zone just to find
> out that the only difference is a change in the version. That is what
> would happen if the client only used ETag and If-None-Match with HTTP.
> This impacts one of the use cases that you championed - namely a simple,
> fixed, device such as a building wall clock that only ever cares about
> one time zone. Do we want all such devices to download the (potentially
> large) time zone data when the only thing that has changed is the version?

I would not expect to be using anything other than 'expand' for an
embedded device with only perhaps a one year look ahead so just perhaps
at most two changes of offset. This just requires that IF there is an
update changing one or more of these forthcoming events then IDEALLY the
ETag for the expand package would change, but as Paul indicates, the
packet may well be a smaller footprint than the ETag label if the range
of the expand perhaps changes daily.

Moving to larger packets. I think I understand part of the
miss-conception on the version model of accessing TZ data. Once a user
has an active sync with the live data, then calling 'list' with  a
'changedsince' of an earlier version will only return a set of TZid's?
The ones which have changed since the earlier version. If none of these
relate to TZid's that the client is currently using there is no need to
download anything, but I would expect the client to bring their local
cached copy up to date. This is where *I* would prefer to be using the
base TZ data since many TZid's these days are using the one master TZ
rule set so as you say 'There is no need to download a lot of TZ data
that has not changed'.

One only needs to read ALL the TZid's of a version if one does not have
a local copy already. Otherwise one reads only the elements needed to
fill the gaps in the version history. I mentioned in a previous post
that probably 90% of TZid data will never change, so every single
version will be the same. Using Paul's point about ETag, every single
version should have the same ETag as there is no point re-downloading.
The problem comes when a single change to say 'central european' generic
rule changes dozens of related TZid's. I would prefer that just the
generic rule changed, but for other users it may be better to flag each
TZid as changed?

Like Paul I also don't see the actual need for ETag since the version
mechanism only requires a single read of each new block of data even if
they are duplicate updates for several TZid's ... It's only the
'changedsince' check of list that needs to be repeated and that only
returns any content if there is a change?

One little sideline here. The race condition where the version changes
AFTER doing a list read but before actually reading the changed data is
covered since the data is read for the version being processed. 'latest'
would not be appropriate against a TZid when processing updates and only
really applies to the list operation.

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