Subject: [Tzdist] Ticket #23

From: Lester Caine <[email-masked]>
Date: Wed, 27 Aug 2014 13:07:10 +0100

I think this is may be covered with other tickets?

Some of the material is still optional. The only procedure that I'm
still concerned about is how we identify the 'version' of VTIMEZONE data
that goes with the 'list' results.

Turning the problem around and 'passing the buck' I think a process
where the publisher creates all the new entries and only then updates
them in a single transaction will work since the list results will match
the new published data.

The problem comes down stream, where the secondary servers now read the
new list and start processing their cached copies. I think the same
sequence can be applied here so while the server has read the new list,
IT does not publish any new data until it's local copy is totally in
sync? Continuing to supply the old data. If for some reason even a
'client' does not complete the download process initiated by the updated
list, then they scrap those updates and retain the older stable version.
Starting the download with a new list call.

Knowing how often I get drop-outs of connection, this is not the most
efficient way of replicating data, but I'm not sure that the dtstamp
process can be used with individual VTIMEZONE packets?

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