Re: [Tzdist] tzdist examples

[Lester Caine <[e-mail]>]

On 11/01/15 01:05, Tim Parenti wrote:
>         ETag does not allow for just the set of changed time zone
>         meta-data to be
>         returned in list action.
> 
>     Sure it does: just ask for the changes since a previous ETag.  I
>     think you mentioned this possibility earlier.  That is, the tzdist
>     protocol needn't invent its own "dtstamp" attribute that is a
>     confusing alternative to ETag; it can just use ETag.  That is,
>     changedsince=XXX should use an ETag for XXX.
>  
> +1.  The only benefit I can see for using a timestamp here instead would
> be if a client is switching between servers, but in that case the client
> should be doing the "modified full sync" anyway, as outlined in #3 of
> Cyrus' post at the head of this
> thread: http://www.ietf.org/mail-archive/web/tzdist/current/msg01174.html

The bit I am still unhappy about is the continuing idea that the only
way tzdist will work is from a blank piece of paper? There is no need
for every user to have to download a complete set of data just because
one server has become inaccessible - perhaps temporarily.

There are a limited number of jobs to be done and how they are done is a
little academic, as long as one can identify some consistent element.

If version is part of the ETag element, then that mechanism can be used
as a part of the process. As long as the 'publisher' selection provides
a consistent set of current AND historic versions, then even a simple
'expand/TZid/period' can be server independent. If the primary server is
no longer available, reading just the expand request from an alternative
source will give the same response. changedsince in my book is simply
how the version element is managed and is needed to flag that we do want
to check for a change rather than a clean read. Embedded devices only
need to remember what publisher and version they are currently using for
perhaps a single TZid and never need a 'full sync' ... They will just
read a single TZid, or a rolling 'expand' and then 'changedsince' is
simply 'no' or a new set of data.

The examples in msg01174 are simply overkill in a lot of cases. If the
client already has 'publisher/version' data set up to a particular
version how ever it is sourced, there is no need to access tzdist other
than to check for a new version. That is either for a single TZid
dataset, or for the full data set, and an ETag or changedsince read of
the list of TZid's will return the same set of id's which ever server is
accessed. This is even more critical when in 50 years time someone is
looking at historic material which is correctly tagged with a publisher
and version. It's not something we can 'add in a later version'!

In the future a new 'publisher' may well become the standard, and that
may well require a complete new rework of all of the material including
mapping TZid's from some old model to a new one, but nothing we are
discussing now affects that process, and while historic archives MAY
need to be completely ported to some new format, access to the original
material also requires that the original publisher dataset is also
maintained.

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