[ticker-dev] Timeout attribute

[Phillips, Matthew]

Hi all,

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.

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.

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, one which, presumably, would need to be programmed to turned itself off at a set changeover date, further confusing things.

Cheers,

Matthew.

> -----Original Message-----
> From: David Arnold [mailto:arnold at dstc.edu.au]
> Sent: Friday, 19 March 2004 9:52 PM
> To: ticker-dev at tickertape.org
> Subject: Re: [ticker-dev] Timeout attribute 
> 
> 
> -->"Ian" == Ian Lister <ticker-lists at lister.dnsalias.net> writes:
> 
>   Ian> It's been a while since we've made any progress on the v3
>   Ian> standard, so I'd like to raise something that's been bugging me
>   Ian> for a long time.
> 
> As an aside, I've been slowly working on the general text of the spec,
> and am basically happy for it to be (finally) published once this
> issue is resolved.  I'll announce the current draft shortly.
> 
>   Ian> The choice of minutes for the units of the Timeout attribute is
>   Ian> a bit odd. The justification at the Ticker workshop for using
>   Ian> minutes rather than seconds (being a standard unit) was that
>   Ian> Tickertape has no real need for sub-minute precision, and
>   Ian> minutes would do just fine.
> 
> While I don't really recall the detail, the minutes of the session
> actually say that we agreed on seconds:
> 
>   
> http://elvin.dstc.com/projects/tickertape/ticker2001/minutes/r
> enaming/index.html
> 
> (which is neither here nor there, but ... anywway)
> 
>   Ian> However, Tickertape notifications often conform to other
>   Ian> protocols, and a timeout is a common concept across many
>   Ian> protocols. Just because Ticker doesn't feel the _need_ to use
>   Ian> anything other than minutes doesn't mean other protocols don't
>   Ian> either.
> 
> ie. see the last comment in the notes on the renaming session at the
> workshop at the URL above.
> 
>   Ian> We measure time arcanely, but the second is a much more sane
>   Ian> unit than the minute. All units smaller than it are decimal
>   Ian> (saves you talking in 0.01666ths of a minute), and it's the
>   Ian> standard international unit for time.
> 
>   Ian> I would like to propose that the Timeout attribute in
>   Ian> Tickertape v3 be measured in seconds.
> 
> As you might have guessed, Ian and I have spoken (well, tickered)
> about this, and I agree, for both the reasons above.
> 
> My reservations were mostly to do with compatibility ...
> 
>   Ian> David has come up with a plan for avoiding problems in the
>   Ian> transition from the current draft implementations (which I'll
>   Ian> leave for him to present), and I can't see any reasons not to
>   Ian> proceed (other than not being bothered, and I'm certainly
>   Ian> bothered :-).
> 
> So, I recorded the timeouts of all public and Mantara internal ticker
> traffic today as a small research task.  Here's the results:
> 
>    Timeout  Number of Messsages
>    ----------------------------
>        2            43
>        5           177
>       10             6
>       60             7
>     1440             6
> 
> I also think that it is a greater problem for the scrolling message to
> disappear too quickly, rather than too slowly.  For example, if the
> timeout was 5 minutes (a popular value), and the message was displayed
> for only 5 seconds, it's likely that it would disappear before it had
> even scrolled onto the screen during busy periods.
> 
> On this basis, and after looking at the UI of some popular tickers, my
> proposal is this:
> 
>    For a limited transition period, the following rules are applied to
>    timeouts on v3 messages:
> 
>    On reception:
>       If 0 < timeout <= 60, treat the units as minutes
>       Elif timeout == 1440, treat the units as minutes
>       Else, treat the units as seconds
> 
>    On sending:
>       If the user selects 1 minute, set the value to 61
>       Else, set the value in seconds
> 
> This will ensure that new clients display messages from old clients
> for sufficiently long that they're readable.  Very old clients (v1)
> will be unaffected (since the TIMEOUT field is still in minutes), and
> the current clients will display things for too long (and will require
> manual deletion).
> 
> Clients should feel free to interpret the timeout in minutes, if they
> want, so long as the on-the-wire value is in seconds.  Having
> user-level control to the nearest second is obviously not necessary.
> 
> Regardless, with new releases of Sticker, eTiks and xtickertape all
> coming soon, and a new release of aquatik long overdue (did i say
> that? :-), the transitional period for new clients should be both
> short, and (I think) bearable in the interim.
> 
> 
> So ... I think this is a good idea.  The more applications we write,
> the more useful it is to have common semantics for same-named
> attributes.  I realise that some might say "I smell ontologies and I
> don't like it", but ... I think this is a simple change with some real
> benefit for future proofing.
> 
> 
> So ... unless I hear strenuous and compelling objections, I'll update
> the spec ... :-)
> 
> 
> 
> 
> 
> 
> d
> 
> 
> _______________________________________________
> ticker-dev mailing list
> ticker-dev at tickertape.org
> http://www.tickertape.org/mailman/listinfo/ticker-dev
>