[ticker-dev] Timeout attribute
Phillips, Matthew
Matthew.Phillips at dsto.defence.gov.au
Mon Mar 22 00:08:49 CST 2004
> On Mon, 22 Mar 2004, Phillips, Matthew wrote:
> >at the risk of coming across as overly conservative ;), and
> while I have
> >occasionally lamented that Timeout does not allow sub-minute values,
> >changing Timeout at this stage seems to add a lot of
> >effort/confusion/complexity for the convenience of allowing
> conformance
> >with other protocols that may use seconds (does anyone use such a
> >beast?). Not to mention that other "conformant" protocols may require
> >millisecond accuracy.
>
> That's OK, Elvin supports floating point numbers too. And working in
> .001's of a second is a lot more sane than working in
> 0.000016666's of a
> minute.
Well, except that floating point doesn't guarantee to exactly represent numbers like 0.001...
> >move). While I'm aware that drafts are named as such because they may
> >change, I think incompatible changes need to be driven by a severe
> >technical shortcoming found in the original.
>
> The change has a pretty compatible migration path. It's not
> like making
> the change breaks interoperability between old draft clients
> and new draft
> clients.
No, but it does mean that interpreting the actual meaning of Timeout may require consulting the User-Agent field and a lookup table ;) Yes, I guess you could avoid the magic numbers of 5 etc if you really mean seconds, but we haven't addressed how old clients seeing, for example, "Timeout: 30" are supposed to know that this means 30 seconds not 30 minutes.
> >My proposal would be to add a new field (eg "Timeout-Seconds",
> >"Lifetime", etc) and include "Timeout" rounded up to the
> nearest minute
> >for backwards compat. Although this is of course bogus, so
> would adding a
> >temporary guess-what-I-really-meant rule to the next round
> of clients,
>
> Fortunately the bogosity in adding the temporary compatibility rule is
> only temporary, whereas putting the bogosity into the final
> standard would
> be rather more permanent.
Temporary, but long-lasting. Like I've said, clients tend to hang around, so old hacks tend to stick around too. Witness the fact that we still haven't switched to ticker 3.0 and currently have 3 different formats. Adding this extra rule makes 4: ticker 3.0draft1 and 3.0final.
I can see this being hugely confusing for little gain - I really think we missed the window of opportunity to do this. We don't even seem to have an actual application for the new timeout field. And although it does appear that several clients will have releases soon, speaking for myself I'm working towards a stable version with features required for Defence HQ use, so a disruptive change like this is unlikely to make the cut.
Cheers,
Matthew.
More information about the ticker-dev
mailing list