[ticker-dev] Elvin presence specification draft

[Wanicki, Martin]

I'll let this stew for a while, and see what others may have to say:-)

Regarding multiple clients using the same user at domain what did you think
about the offline strategy ??

I'm thinking that a status request is very much a thing you do when you
first come on line.
after that one receives and emits notifications for status changes. 
I think it may be reasonable to imply that an offline event is a kind of
status request for clients using the same name at domain pair, your thoughts?

With the heirarchy (for want of a better word) of availability notifications
I'm thinking available beats unavailable at all times.
So another client would only show a person as unavailable when the last of
their clients emits an unavailable?
If this is reasonable then what remains is deciding what type of available
beats another, or should it be time-based.
This, by the way, was another reason for the heirarchy within the possible
numbers used to represent "available", smaller numbers "trump" larger
numbers,
but I'll get off that soap box for now :-)

Cheers and goodluck if your betting on the cup.

Martin



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