[sip-comm-dev] IM status you use


#1

Hi devs,

As far as I'm concerned, I use online/offline, away, busy. Nothing more
since I don't like to give too many details of what I'm doing. It sounds
geek to me :wink:
I read in previous post that knowing SIP Communictor enables to do SIP calls
the status "on the phone" could be interesting indeed.

As said Adam the idle status is interesting. I agree with him. When we have
a phone call or someone knovking at the door, we don't think of putting the
actual status.

JD


#2

Hi all,

Thank you all for your responses, considering what you told me and the limitations of SIMPLE here is what I'll do :

- I'll implement the statuses Online, Busy, On the phone, Away and Offline

- Invisible may be implemented later but as suggested Martin with a possibility of giving to a list of contact the ability to see us anyway. As far as this feature must be protocol independent it's out of the scope of my work for now but may be a good idea for a future implementation.
If you have any suggestion on how handle adding / seeing / removing a contact from the white list, they are welcome !

- The auto-away / auto on the phone / auto idle feature is a very good idea but it must be implemented in a protocol independent way, switching the status of all the accounts of all the protocols in the same time (not just SIMPLE).
Moreover it seems that someone as already worked on the auto away feature (?) so for the moment this good idea rejoin the Invisible state on a todo list. (Emil if you have some informations on the work done for it, I'm interested)

Thanks all,
Ben

路路路

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#3

"IM status" is part of "presence" info that spans more than just the
specific client at which the user might or might not be attending.
Really the client should report presence info, with options, to a
*presence server*, or act as a crude one if there is no presence server.
S-C should have a GUI and logic that allows S-C to compute your presence
state, with explicit user overrides (and defaults), and display of that
data. The presence state of the user should be available (again, with
S-C user override) to other clients querying the presence server, as
well as other users sending a message to the client (eg. a "busy signal"
with a phone, made complex by ignoring call waiting signal to the
phone's user).

聽聽The presence server is useful for a lot more than just the simple state
of a single client, especially when there are different clients for a
single user, distributed geographically, by medium/protocol, or
accessible network (with preferred access, perhaps by $rate charges,
perhaps also varying by calendar/clock).

Presence Info Server: http://en.wikipedia.org/wiki/Presence_information

路路路

On Thu, 2007-07-26 at 11:04 +0200, Benoit Pradelle wrote:

Hi all,

Thank you all for your responses, considering what you told me and the
limitations of SIMPLE here is what I'll do :

- I'll implement the statuses Online, Busy, On the phone, Away and Offline

- Invisible may be implemented later but as suggested Martin with a
possibility of giving to a list of contact the ability to see us anyway.
As far as this feature must be protocol independent it's out of the
scope of my work for now but may be a good idea for a future implementation.
If you have any suggestion on how handle adding / seeing / removing a
contact from the white list, they are welcome !

- The auto-away / auto on the phone / auto idle feature is a very good
idea but it must be implemented in a protocol independent way, switching
the status of all the accounts of all the protocols in the same time
(not just SIMPLE).
Moreover it seems that someone as already worked on the auto away
feature (?) so for the moment this good idea rejoin the Invisible state
on a todo list. (Emil if you have some informations on the work done for
it, I'm interested)

Thanks all,
Ben

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--

(C) Matthew Rubenstein

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#4

Hi Matthew,

I'm sorry but I got some difficulties to understand what you mean. Do you mean that we should use a presence server ? If it's what's you mean, we are using it when it's present on the network.
But my question was about referencing the important and usefull IM states to determine which one we should implement for SIMPLE as far as the protocol allows something like 20 states which is really too much.

Ben

Matthew Rubenstein a 锟絚rit :

路路路

聽聽"IM status" is part of "presence" info that spans more than just the
specific client at which the user might or might not be attending.
Really the client should report presence info, with options, to a
*presence server*, or act as a crude one if there is no presence server.
S-C should have a GUI and logic that allows S-C to compute your presence
state, with explicit user overrides (and defaults), and display of that
data. The presence state of the user should be available (again, with
S-C user override) to other clients querying the presence server, as
well as other users sending a message to the client (eg. a "busy signal"
with a phone, made complex by ignoring call waiting signal to the
phone's user).

聽聽The presence server is useful for a lot more than just the simple state
of a single client, especially when there are different clients for a
single user, distributed geographically, by medium/protocol, or
accessible network (with preferred access, perhaps by $rate charges,
perhaps also varying by calendar/clock).

Presence Info Server: http://en.wikipedia.org/wiki/Presence_information

On Thu, 2007-07-26 at 11:04 +0200, Benoit Pradelle wrote:
聽聽

Hi all,

Thank you all for your responses, considering what you told me and the limitations of SIMPLE here is what I'll do :

- I'll implement the statuses Online, Busy, On the phone, Away and Offline

- Invisible may be implemented later but as suggested Martin with a possibility of giving to a list of contact the ability to see us anyway. As far as this feature must be protocol independent it's out of the scope of my work for now but may be a good idea for a future implementation.
If you have any suggestion on how handle adding / seeing / removing a contact from the white list, they are welcome !

- The auto-away / auto on the phone / auto idle feature is a very good idea but it must be implemented in a protocol independent way, switching the status of all the accounts of all the protocols in the same time (not just SIMPLE).
Moreover it seems that someone as already worked on the auto away feature (?) so for the moment this good idea rejoin the Invisible state on a todo list. (Emil if you have some informations on the work done for it, I'm interested)

Thanks all,
Ben

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#5

Hey Ben,

Sorry for the late response. I think that it might also be a good idea
to have a DND state since many people use it with telephony when they
don't want to be bothered by incoming calls.

I see you have already added a busy state, so I wonder whether it
would not be better to have it renamed to "Do Not Disturb".

What do you think?

Emil

路路路

On 7/26/07, Benoit Pradelle <ze_real_neo@yahoo.fr> wrote:

Hi all,

Thank you all for your responses, considering what you told me and the
limitations of SIMPLE here is what I'll do :

- I'll implement the statuses Online, Busy, On the phone, Away and Offline

- Invisible may be implemented later but as suggested Martin with a
possibility of giving to a list of contact the ability to see us anyway.
As far as this feature must be protocol independent it's out of the
scope of my work for now but may be a good idea for a future implementation.
If you have any suggestion on how handle adding / seeing / removing a
contact from the white list, they are welcome !

- The auto-away / auto on the phone / auto idle feature is a very good
idea but it must be implemented in a protocol independent way, switching
the status of all the accounts of all the protocols in the same time
(not just SIMPLE).
Moreover it seems that someone as already worked on the auto away
feature (?) so for the moment this good idea rejoin the Invisible state
on a todo list. (Emil if you have some informations on the work done for
it, I'm interested)

Thanks all,
Ben

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#6

Yes, that's what I'm talking about. I just want to make sure that S-C
is consistent with the other presence state info that the presence
server is serving. So long as the popular IM states you're polling from
actual users in this thread are supported by the server, and S-C
functions to register (and display) that info, I'm satisfied. It sounds
like I have no reason to worry, as usual :).

路路路

On Thu, 2007-07-26 at 16:52 +0200, Benoit Pradelle wrote:

Hi Matthew,

I'm sorry but I got some difficulties to understand what you mean. Do
you mean that we should use a presence server ? If it's what's you mean,
we are using it when it's present on the network.
But my question was about referencing the important and usefull IM
states to determine which one we should implement for SIMPLE as far as
the protocol allows something like 20 states which is really too much.

Ben

Matthew Rubenstein a 茅crit :
> "IM status" is part of "presence" info that spans more than just the
> specific client at which the user might or might not be attending.
> Really the client should report presence info, with options, to a
> *presence server*, or act as a crude one if there is no presence server.
> S-C should have a GUI and logic that allows S-C to compute your presence
> state, with explicit user overrides (and defaults), and display of that
> data. The presence state of the user should be available (again, with
> S-C user override) to other clients querying the presence server, as
> well as other users sending a message to the client (eg. a "busy signal"
> with a phone, made complex by ignoring call waiting signal to the
> phone's user).
>
> The presence server is useful for a lot more than just the simple state
> of a single client, especially when there are different clients for a
> single user, distributed geographically, by medium/protocol, or
> accessible network (with preferred access, perhaps by $rate charges,
> perhaps also varying by calendar/clock).
>
> Presence Info Server: http://en.wikipedia.org/wiki/Presence_information
>
>
> On Thu, 2007-07-26 at 11:04 +0200, Benoit Pradelle wrote:
>
>> Hi all,
>>
>> Thank you all for your responses, considering what you told me and the
>> limitations of SIMPLE here is what I'll do :
>>
>> - I'll implement the statuses Online, Busy, On the phone, Away and Offline
>>
>> - Invisible may be implemented later but as suggested Martin with a
>> possibility of giving to a list of contact the ability to see us anyway.
>> As far as this feature must be protocol independent it's out of the
>> scope of my work for now but may be a good idea for a future implementation.
>> If you have any suggestion on how handle adding / seeing / removing a
>> contact from the white list, they are welcome !
>>
>> - The auto-away / auto on the phone / auto idle feature is a very good
>> idea but it must be implemented in a protocol independent way, switching
>> the status of all the accounts of all the protocols in the same time
>> (not just SIMPLE).
>> Moreover it seems that someone as already worked on the auto away
>> feature (?) so for the moment this good idea rejoin the Invisible state
>> on a todo list. (Emil if you have some informations on the work done for
>> it, I'm interested)
>>
>> Thanks all,
>> Ben
>>
>> ---------------------------------------------------------------------
>> To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
>> For additional commands, e-mail: dev-help@sip-communicator.dev.java.net
>>
>>

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

--

(C) Matthew Rubenstein

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#7

Ok I understand what you mean. And yes you don't have to worry about it :slight_smile: the states implemented are described in two different RFCs : rfc3863 and rfc4480. So as far as the presence server implements these RFCs (plus the rfc3903 defining how to communicate with a client), it will be able to display our status.

Ben

Matthew Rubenstein a 茅crit :

路路路

聽聽Yes, that's what I'm talking about. I just want to make sure that S-C
is consistent with the other presence state info that the presence
server is serving. So long as the popular IM states you're polling from
actual users in this thread are supported by the server, and S-C
functions to register (and display) that info, I'm satisfied. It sounds
like I have no reason to worry, as usual :).

On Thu, 2007-07-26 at 16:52 +0200, Benoit Pradelle wrote:
聽聽

Hi Matthew,

I'm sorry but I got some difficulties to understand what you mean. Do you mean that we should use a presence server ? If it's what's you mean, we are using it when it's present on the network.
But my question was about referencing the important and usefull IM states to determine which one we should implement for SIMPLE as far as the protocol allows something like 20 states which is really too much.

Ben

Matthew Rubenstein a 茅crit :
聽聽聽聽

聽聽"IM status" is part of "presence" info that spans more than just the
specific client at which the user might or might not be attending.
Really the client should report presence info, with options, to a
*presence server*, or act as a crude one if there is no presence server.
S-C should have a GUI and logic that allows S-C to compute your presence
state, with explicit user overrides (and defaults), and display of that
data. The presence state of the user should be available (again, with
S-C user override) to other clients querying the presence server, as
well as other users sending a message to the client (eg. a "busy signal"
with a phone, made complex by ignoring call waiting signal to the
phone's user).

聽聽The presence server is useful for a lot more than just the simple state
of a single client, especially when there are different clients for a
single user, distributed geographically, by medium/protocol, or
accessible network (with preferred access, perhaps by $rate charges,
perhaps also varying by calendar/clock).

Presence Info Server: http://en.wikipedia.org/wiki/Presence_information

On Thu, 2007-07-26 at 11:04 +0200, Benoit Pradelle wrote:
聽聽

Hi all,

Thank you all for your responses, considering what you told me and the limitations of SIMPLE here is what I'll do :

- I'll implement the statuses Online, Busy, On the phone, Away and Offline

- Invisible may be implemented later but as suggested Martin with a possibility of giving to a list of contact the ability to see us anyway. As far as this feature must be protocol independent it's out of the scope of my work for now but may be a good idea for a future implementation.
If you have any suggestion on how handle adding / seeing / removing a contact from the white list, they are welcome !

- The auto-away / auto on the phone / auto idle feature is a very good idea but it must be implemented in a protocol independent way, switching the status of all the accounts of all the protocols in the same time (not just SIMPLE).
Moreover it seems that someone as already worked on the auto away feature (?) so for the moment this good idea rejoin the Invisible state on a todo list. (Emil if you have some informations on the work done for it, I'm interested)

Thanks all,
Ben

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net


#8

Hey Emil,

As I tell you off list, the DND state isn't a part of the specification so it can't be implemented for SIMPLE. However as we discussed off list, we can locally rename the "busy" state in "busy (DND)" to give a DND state to SC.

Ben

Emil Ivov a 锟絚rit :

路路路

Hey Ben,

Sorry for the late response. I think that it might also be a good idea
to have a DND state since many people use it with telephony when they
don't want to be bothered by incoming calls.

I see you have already added a busy state, so I wonder whether it
would not be better to have it renamed to "Do Not Disturb".

What do you think?

Emil

On 7/26/07, Benoit Pradelle <ze_real_neo@yahoo.fr> wrote:
聽聽

Hi all,

Thank you all for your responses, considering what you told me and the
limitations of SIMPLE here is what I'll do :

- I'll implement the statuses Online, Busy, On the phone, Away and Offline

- Invisible may be implemented later but as suggested Martin with a
possibility of giving to a list of contact the ability to see us anyway.
As far as this feature must be protocol independent it's out of the
scope of my work for now but may be a good idea for a future implementation.
If you have any suggestion on how handle adding / seeing / removing a
contact from the white list, they are welcome !

- The auto-away / auto on the phone / auto idle feature is a very good
idea but it must be implemented in a protocol independent way, switching
the status of all the accounts of all the protocols in the same time
(not just SIMPLE).
Moreover it seems that someone as already worked on the auto away
feature (?) so for the moment this good idea rejoin the Invisible state
on a todo list. (Emil if you have some informations on the work done for
it, I'm interested)

Thanks all,
Ben

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net

---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@sip-communicator.dev.java.net
For additional commands, e-mail: dev-help@sip-communicator.dev.java.net