Re: [Tzdist] tzdist examples

[Daniel Migault <[e-mail]>]

Dear Friends and Colleagues,

Let me wish you a happy new year 2015. We are close to finalize the tz-dist
draft, and I expect it to be closed by next week!

To my knowledge, the only remaining issue is Issue # 32 on
history/changedsince. Cyrus needs some more feed backs from the WG to
determine whether changedsince should stay or should go. Please provide
your feed back by Thursday so Cyrus can provide the last version of the
draft. Most likely, this draft will go to WGLC as all issues have been
addressed.

Best Regards,
Daniel and Eliot

Here is the text from Cyrus that describes the use of changedsince for
synchronization.

So let me clarify by trying to compare the ETag vs changedsince behavior
for monolithic vs incremental version publishers:

1) Full sync /zones
   a) monolithic publisher: returns 500 items
   b) incremental publisher: returns 500 items

2) Poll to sync /zones + If-None-Match - nothing changed
   a) monolithic publisher: returns HTTP 304 status
   b) incremental publisher: returns HTTP 304 status

3) Poll to sync /zones?changedsince - nothing changed
   a) monolithic publisher: returns empty list response
   b) incremental publisher: returns empty list response

4) Poll to sync /zones + If-None-Match - assume one time zone changed
   a) monolithic publisher: returns 500 items
   b) incremental publisher: returns 500 items

5) Poll to sync /zones?changedsince - assume one time zone changed
   a) monolithic publisher: returns 500 items
   b) incremental publisher: returns 1 item

So 5(b) is a win for reducing the size of the response in the case where a
small number of time zones change when using an incremental publisher. Note
that all of the above options are supported by the protocol as it stands
today and can make use of intermediary caching for improved performance
during polling.

Whilst the IANA DB is currently using a monolithic version update scheme,
someone else could decide to republish that data using an incremental
scheme, e.g., by introducing their own per-time zone revision counters.

So I don't want to preclude the possibility of 5(b). So the question is can
we get consensus on whether or not the optimization that 5(b) represents is
worthwhile for the base tzdist specification. The answer to that determines
whether changessince stays or goes...

On Mon, Dec 29, 2014 at 2:48 PM, Ken Murchison <[e-mail]> wrote:

> On 12/26/2014 12:45 PM, Daniel Migault wrote:
>
>> My current understanding is that there is not a strong support for
>> keeping "changedsince" in the current spec, and that it could be left for
>> future work.
>>
>
> I wouldn't go that far.
>
> I agree with Cyrus that changedsince is important to reduce the size of
> the list response for clients looking to update the full set of time
> zones.  This is especially true now that we have added versioning
> information to the list response thus growing its size.
>
> Regardless of whether a client chooses to use changedsince, this
> functionality is fairly trivial to implement in a server, and 3 existing
> servers have already done so.  In fact, this functionality has been interop
> tested doing server to server time zone updates.
>
> --
> Kenneth Murchison
> Principal Systems Software Engineer
> Carnegie Mellon University
>
>


-- 
Daniel Migault
Orange Labs -- Security
[phone]