Re: [Tzdist] tzdist examples

[Paul Eggert <[e-mail]>]

Cyrus Daboo wrote:

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

Yes, I can see that.  Currently there are 588 names and aliases in the TZ 
database, containing 8439 bytes total; if we assume 10000 bytes to represent all 
the names, then under the same assumptions as my earlier message 
<http://www.ietf.org/mail-archive/web/tzdist/current/msg01086.html>, a 
request-response pair without changedsince will be ((600 + 200) + (600 + 10000)) 
bytes for the initial request and 587 * ((600 + 200) + 600) no-change requests 
and 1 * ((600 + 200) + (600 + 4000)) change request, for a total of 838600 
bytes, which is pretty large and slow.  In contrast, 5b) shrinks this to ((600 + 
200) + (600 + 200)) + ((600 + 200) + (600 + 4000)) = 7000 bytes, which is 
considerably better.

The increased efficiency does not help small clients, as they're interested in 
only one zone anyway.  It helps only intermediate servers that are republishing 
the entire databases, or fat clients that always want the full database.  If we 
assume ten updates per year, the savings is (838600 - 7000) * 10 * 8 / (365.25 * 
86400) = 2.1 b/s per intermediate server.  So the question is whether a 2.1 
bits-per-second-per-fat-client optimization is worth complicating the protocol. 
  I can see cases where it might be.

This underscores, by the way, the need for a cheap way to download the entire 
database.  Since the entire tz database can be represented in 26 KB it still 
seems odd to me that we're spending all this time worrying about optimizing 
incremental updates.  But perhaps this can wait until v2 of the protocol.

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

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.

With these two improvement to the protocol I think changedsince= would be OK.