Re: [Tzdist] tzdist examples

[Tim Parenti <[e-mail]>]

On 5 January 2015 at 10:45, Paul Eggert <[e-mail]> 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

One other thing.  It should be acceptable for a server, for whatever
> reason, to ignore changedsince=XXX, and simply pretend that everything has
> changed and to list all the time zones.  This might occur when a server is
> replaced or its time zone publisher changes, or it could merely be a cheap
> server.  That is, the changesince= optimization should be optional on the
> server side.


+1; this is a very good point.

On 23 December 2014 at 13:24, Stephen Colebourne <[e-mail]>
 wrote:

> One final (optional) optimisation is that the ETag of the individual
> zone can be returned in the list response. This is effectively the
> "datatoken", but gives it a much more meaningful definition. Since
> making use of this requires querying the ETag from the clients HTTP
> cache, not all clients will be able to make use of it, but using the
> ETag of the zone response here is much more web-friendly than a second
> random "datatoken".
>

Also, +1 to further investigating Stephen's potential optimization.

--
Tim Parenti