[ticker-dev] Timeout attribute

[Ian Lister]

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.

The initial list of standard attributes I put forward around 18 months ago
describes Timeout as being a number, which doesn't preclude the use of
floating point numbers where appropriate.

>While I'm aware the spec is still technically a draft, it's been "stable"
>for long enough that two major releases of Sticker are based on it, and
>it seems that some people go a long time between upgrading their clients
>(there are still regular Sticker 2.3 users who are quite happy not to
>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.

If you're concerned about reducing the impact of the change even more,
David's original proposal (not sent to the list) observed that the
deployed draft clients use only a small set of discrete timeout values, so
clients interested in minimising impact could interpret those values as
being in minutes and ensure they don't send those values. For example, if
you receive a notification with a Timeout of 5 (the most commonly used
timeout) you can interpret that as being 5 minutes, and if you allow the
user to send a notification with a timeout of 5 seconds (which you
probably wouldn't) you'd actually send it as 6.

Alternatively you can just use the v1 attribute if it exists to be
certain.

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

>one which, presumably, would need to be programmed to turned itself off
>at a set changeover date, further confusing things.

That wouldn't be necessary. It is correct that the draft compatibility
behaviour would only be necessary for a transition period, but after that
period you can just remove the behaviour from future client releases
whenever you get around to it. It won't hurt to keep it there longer if
you don't bother removing it, and it won't hurt if people continue to use
older releases with the compatibility code still in it.

Ian