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

[Lester Caine <[e-mail]>]

On 13/12/14 19:55, Lester Caine wrote:
> 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.

Having now slept on this, a thought comes to mind that if 'changedsince'
IS using a version tag then a logical extension to the download strategy
is that doing a 'get' for a TZid data set and  applying a 'changedsince'
would allow the return to be simply a diff package. Then if the time
frame of interest at the client is outside the modified time frame again
the update can be ignored. Or more exactly one only looks for a change
to displayed data if the modification is in scope. That way, a change to
historic events can be ignored if the client is only interested in
post-2010 and a change to the next offset transition can be flagged with
the smallest of data packet. ( Not sure this is ETag friendly? ;) )

I would consider this a back burner improvement and one that may not be
needed if transmitting the full dataset for each TZid does not prove to
be a bottleneck.

However it flags a problem on how to handle an update covering several
versions. While the current view only needs the final result of several
version changes, the locally cached data may need to use one of the
intermediate versions if that is what is used by a new diary. EVEN over
the course of a current year, some published mater may still be a couple
a of version behind the current one and there is no need to ask for a
new 'changedsince' list each time one changes required version if that
information is already cached locally.

One way of handing this initially may be for the 'changedsince' list to
return only the next version's changes, which the client then processes
and does a further 'changedsince' list using the next version. This
would normally only happen if a client has been switched off for some
time, so I don't think there is ANY need to be able to handle more than
one version update at a time? Except that creating a new local cache
would potentially need the whole version history from day one ... that
may benefit from an extended data get providing all the previous
versions ...

CURRENT application software will have problems with this process since
none of the existing TZ systems allow viewing an older version than
THEIR latest (which ever version that is) and I think it is that hurdle
which may prevent this process being adopted? If the existing code
continues to simply use 'latest' then all of the existing problems
remain and I don't think it breaks anything? Then over time countries
who will benefit more from the security provided by proper version
control can start to leaver it knowing that the underlying tzdist DOES
have access to all the relevant data and that it is being reliably
updated. Material published with an identified version can always be
reliably handled.

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