[ticker-dev] Timeout attribute

[David Arnold]

-->"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/renaming/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