IM status you use

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-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

	"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: htt
p://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-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
> 
-- 

(C) Matthew Rubenstein

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

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: htt
p://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-unsubscribesip-communicator.dev.java.net
>> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
>>
>>     

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

	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: htt
p://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-unsubscribesip-communicator.dev.java.net
> >> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
> >>
> >>     
> 
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
> 
-- 

(C) Matthew Rubenstein

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

Ok I understand what you mean. And yes you don't have to
worry about it 
 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: htt
p://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-unsubscribesip-communicator.dev.java.net
>>>> For additional commands, e-mail:
dev-helpsip-communicator.dev.java.net
>>>>
>>>>     
>>>>         
>>
------------------------------------------------------------
---------
>> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
>> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
>>
>>     

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

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_neoyahoo.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-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
>
>

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net

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 écrit :
> 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_neoyahoo.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-unsubscribesip-communicator.dev.java.net
>> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
>>
>>
>>     
>
>
------------------------------------------------------------
---------
> To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
> For additional commands, e-mail: dev-helpsip-communicator.dev.java.net
>
>
>   

------------------------------------------------------------
---------
To unsubscribe, e-mail: dev-unsubscribesip-communicator.dev.java.net
For additional commands, e-mail: dev-helpsip-communicator.dev.java.net