[sip-comm-dev] MSN Group Chat


#1

Hello devs,

I am near completion of the multi user chat support for the msn protocol, actually I was two weeks ago,
but I was facing some serious problems (euro 2008 :wink: ). But its almost finished and now it is time to clarify some details, so we (Yana and me) thought to ask you about it.

1.
The first Problem we faced was a name problem, if you "join" (in msn you cannot join a room, you get joined :wink: ) a chat room its stored in a list inside the sip-com, so we need names for the chat rooms. For now we take the switchboard id, cast it to a string, and voil� we have a name, but maybe you have a idea for a name convention for the chat rooms. If you create a group chat by yourself you can choose a name, so there actually no name convention needed, but we want to hear as much concepts, ideas as possible.

2.
The next thing is that in the msn protocol group chats are done by some thing they called switchboards, you can create a switchboard and then invite others to it and do multi user chatting. The Problem is that those switchboards are only temporary, so if all the users go offline the group chat is over, if only you go offline you cant reconnect, only a user who is still in the switchboard can invite you and you are back in. So the problem is when you restart the sip-com you have your old chat rooms in your list, but you can't to anything with them, you cannot reinvite users (the switchboard is gone), the only thing you can do with it is reading the history. We thought about deleting the whole list, every time you restart your sip-com (or every time you go offline?), but please tell us what you think about it.

3.
The last thing I remember right now is when someone invites you to a mutli user chat, and you are in his contact list, the switchboard server just puts you in the switchboard list and you will be forced to received messages from that group chat (without asking). Because you have to be in his contact list and you have to authorize that, its not very dangerous that any user abuses that. In the sip-com architecture we have invitation messages and we can use them, but fields like 'Reason' cant be filled with real entries. So the question is, should we call a "fake" invitation message before joining the chat or just join the chat room. The advantage of the first concept is that you can control on which group chats you take part, the advantage of the second concept is that you dont get a "fake" invitation message, which saves you some time ;-)).

It is a little bit hard for me to describe the problems, so if you have understanding problem please answer and I try to specify them again.

Enjoy your weekend.

Cheers
Rupert

···

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


#2

Hey Rupert,

Glad to know you are making progress. I really can't wait to use group chat!

(more inline)

Hello devs,

I am near completion of the multi user chat support for the msn protocol,
actually I was two weeks ago,
but I was facing some serious problems (euro 2008 :wink: ). But its almost
finished and now it is time to clarify some details, so we (Yana and me)
thought to ask you about it.

1.
The first Problem we faced was a name problem, if you "join" (in msn you
cannot join a room, you get joined :wink: ) a chat room its stored in a list
inside the sip-com, so we need names for the chat rooms. For now we take the
switchboard id, cast it to a string, and voilà we have a name, but maybe you
have a idea for a name convention for the chat rooms. If you create a group
chat by yourself you can choose a name, so there actually no name convention
needed, but we want to hear as much concepts, ideas as possible.

I am fine with this approach. I don't think names really matter from a
user perspective so as long as there's no conflict technically, then
we are ok.

2.
The next thing is that in the msn protocol group chats are done by some
thing they called switchboards, you can create a switchboard and then invite
others to it and do multi user chatting. The Problem is that those
switchboards are only temporary, so if all the users go offline the group
chat is over, if only you go offline you cant reconnect, only a user who is
still in the switchboard can invite you and you are back in. So the problem
is when you restart the sip-com you have your old chat rooms in your list,
but you can't to anything with them, you cannot reinvite users (the
switchboard is gone), the only thing you can do with it is reading the
history. We thought about deleting the whole list, every time you restart
your sip-com (or every time you go offline?), but please tell us what you
think about it.

We definitely need to remove them or otherwise we'd endup with an
endless list of dead chats. However, we absolutely need to provide
users with a way to consult their group chat history. How does the
MSN client handle this? How about others like pidgin or adium?

3.
The last thing I remember right now is when someone invites you to a mutli
user chat, and you are in his contact list, the switchboard server just puts
you in the switchboard list and you will be forced to received messages from
that group chat (without asking). Because you have to be in his contact list
and you have to authorize that, its not very dangerous that any user abuses
that. In the sip-com architecture we have invitation messages and we can use
them, but fields like 'Reason' cant be filled with real entries. So the
question is, should we call a "fake" invitation message before joining the
chat or just join the chat room. The advantage of the first concept is that
you can control on which group chats you take part, the advantage of the
second concept is that you dont get a "fake" invitation message, which saves
you some time ;-)).

I'd say that we are not in a position to "fix" behaviour that we don't
like in a certain protocol. If the server puts us in a chat without
asking us then it would be wrong to hide this from the user. If we
give users the option to decline a (fake) chat invitation we could
actually be causing quite a confusion. Such users would believe they
are out of the chat while the other participants would simply perceive
them as silent. They would therefore be expected to participate or at
least know what's being said.

In other words, we don't have the option to reason from a usability
point of view here because the choices have already been made by
protocol designers.

Cheers
Emil

···

On Fri, Jun 20, 2008 at 4:50 PM, Rupert Burchardi <RBurchardi@aol.de> wrote:

It is a little bit hard for me to describe the problems, so if you have
understanding problem please answer and I try to specify them again.

Enjoy your weekend.

Cheers
Rupert

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


#3

Hi Rupert, Emil,

Emil Ivov wrote:

Hey Rupert,

Glad to know you are making progress. I really can't wait to use group chat!

(more inline)

Hello devs,

I am near completion of the multi user chat support for the msn protocol,
actually I was two weeks ago,
but I was facing some serious problems (euro 2008 :wink: ). But its almost
finished and now it is time to clarify some details, so we (Yana and me)
thought to ask you about it.

1.
The first Problem we faced was a name problem, if you "join" (in msn you
cannot join a room, you get joined :wink: ) a chat room its stored in a list
inside the sip-com, so we need names for the chat rooms. For now we take the
switchboard id, cast it to a string, and voil� we have a name, but maybe you
have a idea for a name convention for the chat rooms. If you create a group
chat by yourself you can choose a name, so there actually no name convention
needed, but we want to hear as much concepts, ideas as possible.

I am fine with this approach. I don't think names really matter from a
user perspective so as long as there's no conflict technically, then
we are ok.

I think that this is also an aesthetically issue. What about constructing the name as follows: "MSN Group Chat: [SwitchboardID]". This way when opened in a tab we'll see only the first part of the name. This said I don't really think that the SwitchboardID gives some information to the user, so if we don't use the chat room name also as an identifier, we don't really need this. Another solution could be to show the names of the first two or three participants, for example: "Chat: John, Mary... " or something like that. What do you think?

2.
The next thing is that in the msn protocol group chats are done by some
thing they called switchboards, you can create a switchboard and then invite
others to it and do multi user chatting. The Problem is that those
switchboards are only temporary, so if all the users go offline the group
chat is over, if only you go offline you cant reconnect, only a user who is
still in the switchboard can invite you and you are back in. So the problem
is when you restart the sip-com you have your old chat rooms in your list,
but you can't to anything with them, you cannot reinvite users (the
switchboard is gone), the only thing you can do with it is reading the
history. We thought about deleting the whole list, every time you restart
your sip-com (or every time you go offline?), but please tell us what you
think about it.

We definitely need to remove them or otherwise we'd endup with an
endless list of dead chats. However, we absolutely need to provide
users with a way to consult their group chat history. How does the
MSN client handle this? How about others like pidgin or adium?

3.
The last thing I remember right now is when someone invites you to a mutli
user chat, and you are in his contact list, the switchboard server just puts
you in the switchboard list and you will be forced to received messages from
that group chat (without asking). Because you have to be in his contact list
and you have to authorize that, its not very dangerous that any user abuses
that. In the sip-com architecture we have invitation messages and we can use
them, but fields like 'Reason' cant be filled with real entries. So the
question is, should we call a "fake" invitation message before joining the
chat or just join the chat room. The advantage of the first concept is that
you can control on which group chats you take part, the advantage of the
second concept is that you dont get a "fake" invitation message, which saves
you some time ;-)).

I'd say that we are not in a position to "fix" behaviour that we don't
like in a certain protocol. If the server puts us in a chat without
asking us then it would be wrong to hide this from the user. If we
give users the option to decline a (fake) chat invitation we could
actually be causing quite a confusion. Such users would believe they
are out of the chat while the other participants would simply perceive
them as silent. They would therefore be expected to participate or at
least know what's being said.

In other words, we don't have the option to reason from a usability
point of view here because the choices have already been made by
protocol designers.

Agree.

Another thing we should discuss is that we should add the possibility to easily transform a simple chat into group chat. Add a button the current simple chat panel that would allow to invite other contacts to the chat. This will require some modification on both sides - gui and protocol. Rupert, do you have any ideas how we could easily implement this?

Cheers,
Yana

···

On Fri, Jun 20, 2008 at 4:50 PM, Rupert Burchardi <RBurchardi@aol.de> wrote:

Cheers
Emil

It is a little bit hard for me to describe the problems, so if you have
understanding problem please answer and I try to specify them again.

Enjoy your weekend.

Cheers
Rupert

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


#4

Hey Emil and Yana,

thank you for your responses.

to 1.) ("Name issue")
I agree to both of you ;-), on the one hand I think the names actually don't matter on the other hand just a number as title does not look really good.
I don't like Yanas second idea with the names of the chat participants, even if this is the way the official client handles the name issue.But I would also support a
solution with something like "MSN Group Chat [SID]", maybe without that "Group Chat".

to 2.) ("Chat room list")
I have problems to remove the dead chat rooms, even if I remove them from the chatRoom"Cache" they appear in the list, do you have ideas how to remove them?
I've also checked the official client about the history issue. The msn client saves for every message entry a field with all the receivers.

to 3.) ("Invitation or not")
I removed the invitation message, and I think thats the best way for the MSN group chat.

to 4.) "Rupert, do you have any ideas how we could easily implement this? "
First I thought we should just copy the invite button to the basicChatWindow, but this would not work correctly. The single chat room window would became unnecessary, when you invite another user to the chat, because
you receive them in a new group chat window. So I think we should leave the MSN group chat a little bit buggy or we should remove the whole BasicChatOpSet. If we do the second approach we need a new solution for the group chat history.

I am now kind a stucked, because I tried to optimize it now for about 2 weeks and it doesn't really worked out. So I think I'll start this week with the Yahoo group chat, after I finished the documentation and the "chat room list" issue.
If anyone wants to beta test the msn group chat, I can send him/her the msn protocol bundle, I tried to set up a patch file, but unfortunately I don't find a way to create it with my branch and the correct rev. at the repository.

Cheers Rup.

Yana Stamcheva wrote:

···

Hi Rupert, Emil,

Emil Ivov wrote:

Hey Rupert,

Glad to know you are making progress. I really can't wait to use group chat!

(more inline)

On Fri, Jun 20, 2008 at 4:50 PM, Rupert Burchardi <RBurchardi@aol.de> >> wrote:

Hello devs,

I am near completion of the multi user chat support for the msn protocol,
actually I was two weeks ago,
but I was facing some serious problems (euro 2008 :wink: ). But its almost
finished and now it is time to clarify some details, so we (Yana and me)
thought to ask you about it.

1.
The first Problem we faced was a name problem, if you "join" (in msn you
cannot join a room, you get joined :wink: ) a chat room its stored in a list
inside the sip-com, so we need names for the chat rooms. For now we take the
switchboard id, cast it to a string, and voil� we have a name, but maybe you
have a idea for a name convention for the chat rooms. If you create a group
chat by yourself you can choose a name, so there actually no name convention
needed, but we want to hear as much concepts, ideas as possible.

I am fine with this approach. I don't think names really matter from a
user perspective so as long as there's no conflict technically, then
we are ok.

I think that this is also an aesthetically issue. What about constructing the name as follows: "MSN Group Chat: [SwitchboardID]". This way when opened in a tab we'll see only the first part of the name. This said I don't really think that the SwitchboardID gives some information to the user, so if we don't use the chat room name also as an identifier, we don't really need this. Another solution could be to show the names of the first two or three participants, for example: "Chat: John, Mary... " or something like that. What do you think?

2.
The next thing is that in the msn protocol group chats are done by some
thing they called switchboards, you can create a switchboard and then invite
others to it and do multi user chatting. The Problem is that those
switchboards are only temporary, so if all the users go offline the group
chat is over, if only you go offline you cant reconnect, only a user who is
still in the switchboard can invite you and you are back in. So the problem
is when you restart the sip-com you have your old chat rooms in your list,
but you can't to anything with them, you cannot reinvite users (the
switchboard is gone), the only thing you can do with it is reading the
history. We thought about deleting the whole list, every time you restart
your sip-com (or every time you go offline?), but please tell us what you
think about it.

We definitely need to remove them or otherwise we'd endup with an
endless list of dead chats. However, we absolutely need to provide
users with a way to consult their group chat history. How does the
MSN client handle this? How about others like pidgin or adium?

3.
The last thing I remember right now is when someone invites you to a mutli
user chat, and you are in his contact list, the switchboard server just puts
you in the switchboard list and you will be forced to received messages from
that group chat (without asking). Because you have to be in his contact list
and you have to authorize that, its not very dangerous that any user abuses
that. In the sip-com architecture we have invitation messages and we can use
them, but fields like 'Reason' cant be filled with real entries. So the
question is, should we call a "fake" invitation message before joining the
chat or just join the chat room. The advantage of the first concept is that
you can control on which group chats you take part, the advantage of the
second concept is that you dont get a "fake" invitation message, which saves
you some time ;-)).

I'd say that we are not in a position to "fix" behaviour that we don't
like in a certain protocol. If the server puts us in a chat without
asking us then it would be wrong to hide this from the user. If we
give users the option to decline a (fake) chat invitation we could
actually be causing quite a confusion. Such users would believe they
are out of the chat while the other participants would simply perceive
them as silent. They would therefore be expected to participate or at
least know what's being said.

In other words, we don't have the option to reason from a usability
point of view here because the choices have already been made by
protocol designers.

Agree.

Another thing we should discuss is that we should add the possibility to easily transform a simple chat into group chat. Add a button the current simple chat panel that would allow to invite other contacts to the chat. This will require some modification on both sides - gui and protocol. Rupert, do you have any ideas how we could easily implement this?

Cheers,
Yana

Cheers
Emil

It is a little bit hard for me to describe the problems, so if you have
understanding problem please answer and I try to specify them again.

Enjoy your weekend.

Cheers
Rupert

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

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