[ticker-dev] Elvin presence specification draft

[Wanicki, Martin]

I just remebered a conversation that was had about groups & domains that
kind of contradicts what I said about what trumps what, but I cant remeber
the outcome, so forgive me if what I proposed about using the user at domain
pair to manage this is all wrong ..:-(

> ----------
> From: 	Phillips, Matthew[SMTP:Matthew.Phillips at dsto.defence.gov.au]
> Sent: 	Tuesday, November 06, 2001 12:56 PM
> To: 	'Wanicki, Martin'
> Cc: 	'ticker-dev (E-mail)'
> Subject: 	RE: [ticker-dev] Elvin presence specification draft 
> 
> > 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.
>