[ticker-dev] Elvin presence specification draft

[Wanicki, Martin]

David may have said...	
> ----------
> From: 	David Arnold[SMTP:arnold at dstc.monash.edu.au]
> Reply To: 	davida at pobox.com
> Sent: 	Monday, November 05, 2001 4:11 PM
> To: 	ticker-dev (E-mail)
> Subject: 	Re: [ticker-dev] Elvin presence specification draft 
> 
> -->"Martin" == Wanicki, Martin <Martin.Wanicki at Australia.Boeing.com>
> writes:
> 
>   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.
> 
David> i don't really care either way here.  both are defined patterns of
> David> bits.  if one particular language group can benefit from simpler
> David> recognition of that bit pattern, that's fine with me.  but not
> having
> David> that is also ok if there's some benefit.
well it is if we have some defined status enums .. see later


>   Martin> This leaves us with an "online" status change and an
>   Martin> "off-line" status change with "online" being one of
>   Martin> available/unavailable
> 
> David> if you rename "available" to "online" here, don't you have the same
> David> thing?  
its only vice versa renamning "online" to "available" because there may 
be many kinds of available all of which mean online as well 


>   Martin> Status becomes a number. Negative One (-1) = off-line Zero (
>   Martin> 0 ) = Available Positive Non-Zero (1..???)  = some
>   Martin> "Unavailable" status event
> 
> David> what is the expected benefit of having machine-readable variations
> on
> David> "unavailable"?
well its started out to facilitate the "Coffee" status, but if the protocal
is to facilitate "Coffee" why stop there?
There are many common reasons for unavailability and if we capture the vast
majority of "common" ones we
facilitate a language independance and a set client behaviour.

>   Martin> Appointment|Lunch|Coffee|....more.....
> 
> David> the only thing i can see being actually useful, from a
> David> machine-readable point of view, is an expected duration of the lack
> of
> David> availability.
> 
that currently doesnt exist in the protocol, only an elapsed time, which to
me is ok cause an 
expected duration is only a guess but when one gets back to their client and
changes the status, the status actually represents activity
where unavailable represents inactivity (kind of)


> David> i don't see any benefit in having different codes for "meeting" vs
> David> "lunch" (for example).
refer to the "Coffee" explanation above..


> David> some thoughts ...
> 
> 
> David> for my usage, "offline" is useless.  i'm never (or so infrequently
> as
> David> to be insignificant) offline.  one or more of my sessions (and
> David> therefore presence tools) is running at all times.
Perhaps from you.. but "To" you isnt it useful to know, say, Bill is
offline? versus unavailable.


> David> i'm happy that some people have a different usage pattern which
> might
> David> make this value meaningful, but i'm not sure i want my client
> programs
> David> sending an "offline" by default when they exit, because it's not
> David> necessarily true.
> 
> David> i think explicitly set textual status messages, with an explicit
> David> indication of "available/online" or "unavailable" are useful.  i
> will
> David> do that at least some of the time.
Agreed

> David> i think automatic "unavailable?" and "available?" status values are
> David> useful.  i am very likely to walk away-from/up-to my machine and
> David> forget to set the status text.  
also agree..

> David> imagine that at midday, you want my status, and get
> 
> David>     last status:    in meeting @ 10:55am
> David>     last activity:  11:54am
> 
> David> that would be kinda useful.  you can reasonably guess that i'm back
> David> from my meeting but haven't set my status yet.  not that we'd
> David> necessarily want all presence tools to have to monitor key/mouse
> David> activity.  it could also be construed as an invasion of privacy ;-)
Agree whole hartedly, one of the reasons I support the notion on unavailable
until notified otherwise..

> David> i don't know what's best here.  i need to play/think more :-(
:-)


Martin