[ticker-dev] Elvin presence specification draft

[Wanicki, Martin]

Dear ticker-dev(ers) 

Been thinking a lot about this now that I've had a chance to implement this
in a little winblows & com based 
presence app, and have these *Humble* opinions to add.

My comments and Ideas are only concerning the Status & status-text fields
and their logic and use.

Firstly, the status field should not be a string, or else why do we have a
status text field.
I understand the concept of making it readable *but* its only readable in
English :-) 
Sooooo to that end I put forward that the status field should be a machine
readable value (a number)
that has the same meaning in any language.

The status-text field should be used to describe the reason for the status
change.
This leads me to my next point.. the actual status states...

Online.. yep this sounds good on the surface but what happens immediately
after an online message ?
I would suggest, an available/unavailable/off-line/coffee... etc. would be
the next logical event which would almost
immediately overwrite the online event. 
So lets drop it, online can be derived by anything that is not a off-line
event.

This leaves us with an "online" status change and an "off-line" status
change with "online"  being one of available/unavailable

I do see possible requirements for some more defined status-changes so to
that end suggest we either keep it simple
and have single status change with the description explaining the status
*OR* we have a defined enumerated type
that explains the reason for the status change. 

Sooooo here's my suggestion.

Status becomes a number.
            Negative One  (-1)			= off-line
	Zero	         ( 0 )			= Available
	Positive Non-Zero	(1..???) 	= some "Unavailable" status
event	

Lets define some of the unavailable events as part of the standard
and provide user-defined unavailable status events at, say, anything over
100 

here are a few to start with ..  

				Appointment|Lunch|Coffee|....more.....

Hey, by defining these constant values we also begin to facilitate language
independence!  :-)
	

What follows are just some other implementation ideas thrown open to debate 

	Person is Available    (human selected option)
	Person is Unavailable  (human selected option)
	No Client activity for X mins  - configurable (machine selected
option)

With just these three, consider the following example ...

Client_1 application starts and the client software interrogates
configuration data to decide if the person
wants to be available by default or not then the client emits an
available/unavailable message as appropriate.

Receiving Client_2 can interpret this non-negative value as an online event
and the maintain their registry according to the actual value & the
status-text (if supplied)

Assuming Client_1 sent an "Available" and then the person operating Client_1
steps away from their computer for a while,
Client_1 could emit a No_Client_Activity status is an implied unavailable
status according to some configurable rule

Client_2 would be aware the Client_1 is on the network and that the person
operating Client_1 may eventually see any messages posted to them.

Ok thats it for this one, please excuse the rambling nature of my
suggestions, I *think* I have it all down from 
thoughts I had over the weekend.

Cheers

Martin