[ticker-dev] Timeout attribute

[David Arnold]

-->"Matt" == Phillips, Matthew <Matthew.Phillips at dsto.defence.gov.au> writes:

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

  Matt> No, but it does mean that interpreting the actual meaning of
  Matt> Timeout may require consulting the User-Agent field and a
  Matt> lookup table ;) Yes, I guess you could avoid the magic numbers
  Matt> of 5 etc if you really mean seconds, but we haven't addressed
  Matt> how old clients seeing, for example, "Timeout: 30" are
  Matt> supposed to know that this means 30 seconds not 30 minutes.

My assumption here is two-fold:

a) The timeout is the least important piece of information in the
   message, and if it's misinterpreted or even totally ignored, that's
   both legal (from a specification point of view) and reasonably
   acceptable from a user's point of view.

b) The current user-base is both small and technically literate
   compared to the userbase we'd hope for in the future.  This means
   that it's fairly easy to say now that "you have to upgrade to make
   this work right" compared to saying that in the future when the
   joint chiefs are using it :-)

So I was proposing a very simple transition (and certainly not
anything as elaborate as looking at User-Agent values).

The fact that messages to various public channels used timeouts
ranging from 1 to 60 minutes for postings indicated to me that people
either didn't care about the expiry time, or overrode the extreme
values in their client anyway.

  Matt> Temporary, but long-lasting. Like I've said, clients tend to
  Matt> hang around, so old hacks tend to stick around too. Witness
  Matt> the fact that we still haven't switched to ticker 3.0 and
  Matt> currently have 3 different formats. Adding this extra rule
  Matt> makes 4: ticker 3.0draft1 and 3.0final.

I think a large part of the reason for the prolonged life of v1 is
that v3 is not finalised.  The reason it's not finalised is that it
has some problems.  So I'm trying to remove those problems, so it can
be finalized, so we can then get rid of v1 and draft-based v3
implementations.


  Matt> I can see this being hugely confusing for little gain - I
  Matt> really think we missed the window of opportunity to do
  Matt> this.

I am sympathetic to your position -- you've got a good user base, a
stable code base, and making changes is painful.

I can only say that it's my feeling that this is a minor issue in the
greater scheme of tickertape, and getting it closer to right is worth
the minor pain.

  Matt> We don't even seem to have an actual application for the new
  Matt> timeout field.

There are other message formats that use timeouts, and could benefit
from a common definition.

However, that's not really the point -- TIMEOUT also worked just fine,
but we changed it to Timeout because we thought that was better, and
worth the pain.

  Matt> And although it does appear that several clients will have
  Matt> releases soon, speaking for myself I'm working towards a
  Matt> stable version with features required for Defence HQ use, so a
  Matt> disruptive change like this is unlikely to make the cut.

I'd hoped it wasn't majorly disruptive -- users, especially those at
Defence HQ who will all be using the new client, are unlikely to even
be aware that this has changed.

I reckon the long-term benefits outweigh the cost, but ...




d