Nathan Myers wrote:
From: Paul Eggert <eggert@twinsun.com>:
Other solutions would reduce the IP traffic even further. For example, the time zone server could notify the clients of changes instead of requiring the clients to poll the server. This could be done via multicast to cut down on packet transmission even further.
A "push" policy (with attendant daemons, subcriptions, etc) would be a hard sell for something like time zone information that changes so infrequently, and has such a low perception of importance among those not subscribed to this list.
Um... I beg to differ (a lot). Here in continental Europe, we have a major difference in the timezone policy last autumn, which were for some of us the first year we live with Windows '95. In case you don't know, Windows '95, when compared with Windows 3.x, add the benefit of an automated following of DST changes. But this benefit have been canceled last year; as Windows '95 was programmed for the ancient rules, it failed two times: - first at the end of september, when it announced falsely the end of summer time; - and then at the end of october, when it failed to announce the end of summer time... For some people, who are not MS enthouiast, this was interpreted as a major failure of Windows '95, with the obvious solution that the better would be to drop the DST control by the OS (or better, to drop that OS...) As an evidence, all these peoples which were annoyed don't subscribe to this list. And I'm sure that they (as a whole) would benefit of a "push" protocol in order to keep their computers' clocks right. IF THIS DON'T COST ANYTHING TO THEM. (Well, if it is a few cents, I think it will be OK. But continuous polling, or polling every day, for peoples connected to Internet via modems and private phone lines, is IMHO inacceptable.)
If you're stuck with a protocol in which the client must poll the server, then probably the best you can do is have the clients poll once after each reboot or reconnect, and also once a day at a random time. One packet-exchange per day should be acceptable overhead for almost all applications.
It sounds like a NNTP-like protocol, doesn't it? Thus, can NNTP be extended to signal a change in TZ information? (This is just an idea out of my head, I don't know the internals of NNTP, so I know nothing about the feasability). Antoine Leca