[ticker-dev] Timeout attribute

[David Arnold]

-->"Ian" == Ian Lister <ticker-lists at lister.dnsalias.net> writes:

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

  Ian> That doesn't seem too unreasonable.

I'd be happy with that too.


  Ian> I was wondering why we called it org.tickertape.message instead
  Ian> of message.tickertape.org? I remember there was an minor
  Ian> argument in favour of the latter because it allowed string
  Ian> comparisons called in the case of hash collisions to complete
  Ian> slightly quicker, but I can't recall any arguments in favour of
  Ian> the former. The minutes that David posted the other day
  Ian> (http://elvin.dstc.com/projects/tickertape/ticker2001/minutes/renaming/index.html)
  Ian> also refer to a tickertape.elvin.org attribute. Anyway, this
  Ian> might be a possible way out if we wanted to change the name of
  Ian> that attribute at the same time as changing Timeout... :-)

eek!

Ok.  Since tickertape.org (the collective wisdom and presence implied
by this mailing list) "owns" the domain name tickertape.org, I think
it makes sense to use tickertape.org as the root of the protocol
identifier.

Whether the namespace should run general->specific (JANET, Java, etc),
or specific->general (DNS), I don't really know.

Making that decision on the basis of a very minor optimisation in one
implementation of the Elvin client access protocol seems a little
silly to me :-)

If we could change the field name, and consequently keep the version
number at 3000, that might be a compromise I'd be interested in,
although it seems like some additional complexity in the apps?

  Ian> Perhaps we should take this as a lesson that in future we
  Ian> shouldn't have clients implemementing a draft claim to
  Ian> implement the final standard? Although with a purely numeric
  Ian> version that might get a bit ugly.

I think the biggest lesson is "don't let draft protocols drag out for
3 years"  :-/

But, more concretely, i think you're right -- having draft protocols
using the final spec version number is asking for trouble.

I can't think of a simple solution though .. 2999 seems a bit broken.
Why do we have 1000 micro versions again?

Maybe 3.0final should be 3010 ?





d