[ticker-dev] Elvin presence specification draft

[Phillips, Matthew]

> Folks,
> 
> Reply to Matthew's comments..
> 
> > >   Martin> Firstly, the status field should not be a 
> string, or else
> > >   Martin> why do we have a status text field. I 
> understand the concept
> > >   Martin> of making it readable *but* its only readable 
> in English :-)
> > >   Martin> Sooooo to that end I put forward that the status field
> > >   Martin> should be a machine readable value (a number) 
> that has the
> > >   Martin> same meaning in any language.
> > > 
> > > i don't really care either way here.  both are defined patterns of
> > > bits.  if one particular language group can benefit from simpler
> > > recognition of that bit pattern, that's fine with me.  
> but not having
> > > that is also ok if there's some benefit.
> > 
> >I with David here, you might as well choose a representation that is
> >meaningful to _someone_
> 
> If status is an integer it facilitates extension of the 
> protocol without
> re-hacking all clients
> the values I chose (and have since thought more about and 
> re-chosen) were
> for this reason 
> 	A positive number - regardless of what it is an 
> unavailable event 
> 	An "offline" event is never going to be anything else 
> so 0 is fine
> (yes, I've switched available and offline)
> 	An "available" event, although hardly likely to be 
> anything else,
> may in some point in the 
> 		furure require more granularity, so it can fit into the
> negative number domain. 
> 
> Clients need only to interperet them as   ( negative || zero 
> || positive )
> or clients can choose the more granular interperetations in 
> the ranges of
> ([-maxint .. -1]  || [0] || [1..maxint])
> this gives us scaleability without making older clients redundant.

Yes, but I can't see Status needing other values: you are either online,
unavailable (but runnning a client) or offline entirely.  If we _do_ need to
extend it eg to formally indicate 'temporarily' offline, we could easily do
this using something like 'offline temporary'.

I had forgotten about the standard 'coffee' status, and I can see now where
you're coming from: 'coffee' should be Status = "unavailable" and
Status-Text = "Coffee".  I actually put this in as a special case as a way
to allow CoffeBiff to be done via presence, and I can't any other special
cases creeping in.

> So at the very least, I suggest we keep the status to the basic three
> call them what you may, I like "available"|"unavailable"|"offline"
> I'd be happier if we did use numbers because I like the 
> option of being able
> to use the granularity 
> of the ranges to extend the meaning and not rely on the 
> status text at all,
> but this is not imperative 
> to the ratification of this spec, just something I percieve 
> as useful, and
> scaleable.

I am of the belief that you should be able to look at a notification and get
an idea, a priori, of what it means.  So using coded numbers for concepts
that aren't numeric worries me.  I agree with your scalability concern
though: perhaps we should allow clients to postfix extra info to Status, eg
the 'offline temporary' idea?  This would allow future 'subclasses' of the
standard three states.

Cheers,

Matt.