Re: [Tzdist] tzdist examples

[Lester Caine <[e-mail]>]

On 12/01/15 00:34, Paul Eggert wrote:
> Lester Caine wrote:
>> It is only that the accessing URL needs to provide the
>> current version in order to know that the server now has a new version
>> to provide,
> 
> No, the ETag does not need to be part of the URL: it's a separate
> component of the protocol.  A client can use a conditional GET with an
> ETag to get either the latest version or an indication that the client
> already has that version.  That is how a client can know whether the
> server has a new version without putting an explicit version number in
> the accessing URL.

Something is getting lost in the translation from brain to paper ;)

If one looks up a page using a URL, the hash returned by the lookup as
the ETag will change if the underlying content is different. If I ask
for /expand/version/TZid ETag will be a fixed value which ever server
provides it. Use /expand/version/TZid/since then the ETag will return
the current version hash rather than requested version one.

Drop the 'version' element and one can't move between servers safely
since one does not know what is current at the alternate server. The URL
needs to  provide a version to work with, but also identify if it wants
the extra information that this version is not now the current one.

I THINK I am right when I say that if properly specified in tzdist, a
client can create a local ETag for all of the data it already has cached
and use that with the request for updates from the server without having
to have first read that data from a server? /list/version/since would
skip a download if the ETag of the local information matches the server
response?

>> if a server has not been updated an error
>> is provided if the replacement server does not actually understand the
>> version being requested.
> 
> Sorry, I'm not following this.  Are you thinking of a scenario where the
> client has a more-recent version than the server?  That's a problem, I
> suppose, but it's not a problem tzdist should try to solve.

It is EXACTLY the race condition I am trying to avoid! If the diary I am
working with is built using a server that has yet to be updated. That is
the APPLICATION has yet to be notified that there has been a change, but
overnight I'm looking at a server that has already received the update,
my version is more recent than the one being used by my information source.

I can see the situation in the future where publishers trying to get
ahead of the game publish short term changes only to have the change
cancelled a few hours later. THAT is the sort of problem that
'changedsince' could iron out, since a TZid may appear in version+1 and
then go again in version+2 so a /expand/TZid/version/since would flag a
change of version number, but no change of content for that expand period.

/list/version/since where version is not available from a new server
being accessed would fail as invalid. This may be because the server has
not retained historic records, or because for some reason it has not
actually been updated. Both ARE potential problems which tzdist has to
handle.

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