[ticker-dev] Timeout attribute

[Phillips, Matthew]

Well, David's well-considered arguments and a re-reading of the workaround proposal (plus a really nice cup of coffee) have gone a long way towards convincing me. Although whenever I think of how I'm going to explain this translation requirement to others, I still cringe. Several prople writing producers have already been amazed that there are three formats for doing essentially the same thing. But I take the point that Timeout isn't very important anyway.

How about this as a way to ease the transition: 3.0final messages using the new Timeout get a "org.tickertape.message: 3001" tag, messages with "org.tickertape.message: 3000" are 3.0draft1 and messages with no version field are considered to be 3.0final. This allows next-release clients to detect what the units of Timeout are from older clients. It doesn't remove the need to translate on sending, but has the nice effect that clients looking for org.tickertape.message == 3000 as a marker of v3 message content will read the v1 content instead and not see the 60-fold timeout increase. Not sure about other clients, but this works well for Sticker, and at least won't make it any worse for others. With this scheme, the 50+ Sticker's that I see currently running will ignore the new Timeout and won't suddenly get spammed with "immortal" ticker messages between the point that we start testing the new format and they upgrade to 3.1.

Cheers,

Matt.

> -----Original Message-----
> From: David Arnold [mailto:arnold at dstc.edu.au]
> Sent: Monday, 22 March 2004 8:08 PM
> To: ticker-dev at tickertape.org
> Subject: Re: [ticker-dev] Timeout attribute 
> 
> 
> -->"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
> _______________________________________________
> ticker-dev mailing list
> ticker-dev at tickertape.org
> http://www.tickertape.org/mailman/listinfo/ticker-dev
>