Re: [Tzdist] Comments on timezone-service-11 sections 1 thru 4

[Ken Murchison <[e-mail]>]

On 08/21/2014 04:44 AM, Lester Caine wrote:
> On 21/08/14 01:58, Ken Murchison wrote:
>>> Some actions return iCalendar packages and others return JSON packages.
>>>
>>> Just seems a mess?
>> I disagree.  All response bodies in this protocol are JSON with the
>> exception of the response to a get action, which can be whatever
>> supported format the client requests (defaulting to iCalendar).  As with
>> any other HTTP-based protocol, success and errors are signaled using
>> HTTP response codes.  In the case of errors, this protocol provides more
>> detailed info on the error in a structured JSON response body.  Seems
>> pretty simple and straightforward to me.
> It's not so obvious when one is coming to this cold ;)
>
> So actually what we are missing is the JSON definition for a get return,
> which could then follow the format of the other returns with a dtstamp
> for consistency? I think I've identified what I was  missing below ...

A client can certainly request format=application/calendar+json if it 
wants a JSON response.  In either case, the server will return an ETag 
which the client can use in a conditional request to see if the timezone 
data has changed.


>
> Again still on a learning curve here ... why is there no provision to
> return at least 'expand' as an icalendar format list? I can see how the
> capabilities can be expanded, but it seems to me if there is an option
> to return XML or iCalendar in addition to a base of JSON then all
> functions should provision that rather than having to add those details
> outside the core specification?

Interesting idea.  This would have to be iCalendar using just RDATEs and 
not RRULEs, since the point of expand is for the server to expand 
recurrences, not the client.  I don't know if this is any better than 
the existing JSON response.


> CalDAV and iCalendar are data consumers, and just need a subset of data,
> in the right format, appropriate to there applications. Building a
> mirror server is not particularly bothered by the format of how the data
> is transferred, but for scalability and speed of propagating changes the
> function I am looking to create for the base tz data as an 'update'
> function that will only pass those timeoneid's which have changes and if
> those changes will affect already archived data. Even current day
> scheduling needs the ability to identify and report short notice changes
> to DST activity which there have been several examples of already in the
> past few months. The 'changedsince' action buried in expand SHOULD also
> be an integral part of 'get' for server updates?

Updating a secondary server is covered in section 4.1.3 
<http://tools.ietf.org/html/draft-douglass-timezone-service-11#section-4.1.3> 
of the draft.  The secondary requests the list of timezones that have 
changedsince its last update and then fetches them with get actions.


> In the case of a 'light' consumer where the local diary has recorded a
> meeting for next week, if the user accesses that data and uses a new
> lookup on the tzdist, the dtstamp may flag that there has been a change
> but identifying if that change has affected the current lookup would be
> difficult locally. In this case I am not sure if the 'changedsince' is
> sufficient, but I think it can be used with the right workflow. Kicking
> out the '304 HTTP' at least identifies there is no need to do anything
> and the server just needs a fast way of calculating that.

In this case, if the client had a done previous expansion around the 
given date, it could use the ETag from that response and do a 
conditional expand request with the same parameters, which will either 
result in a 304 (nothing changed) or a 200 with the updated set of 
occurrences.

-- 
Kenneth Murchison
Principal Systems Software Engineer
Carnegie Mellon University