GNOME.org
 

Re: [Ekiga-devel-list] On rewriting the text chat stack

Hi,
Thanks, Julien, if you could implement the chat, right now it is the only important regression I think (compared to v4).
First of all, I think it is essential to implement ONLY ONE METHOD, completely and bug-free, so that it becomes usable by all users. It should especially be avoided to implement several protocols and none of them working. Better to have one protocol working in 2 months than all of them working only in several years by now. In my opinion, 200-400 lines dealing with chat backend can be later updated to another protocol, if really needed.
Second point, currently we do not have enough man-power to implement all the open chat protocols you mentioned. I wonder if we will ever have, knowing that there are other things in Ekiga which are more important in my opinion (secure videoconferencing, Ekiga.net, multi-user conference, echo cancelling etc. etc.) Again, let's work on only one of them so that a person can send a message to another one (one to one, not one to many), in particular to the one he is doing videoconference with.
Third, as far as I understand, SIP MESSAGE, or better MSRP if possible in a reasonable time, is the most appropriate chat protocol in our case. Ekiga's main mission is videoconferencing, not supporting all chat protocols, for which there are other programs, much more advanced than Ekiga.
Finally, would you mind to contact us when you will work on GUI for chat? For example, should text chat be in the same window as the video, or on its own? I do not yet have an idea...
As a side note, see also https://bugzilla.gnome.org/show_bug.cgi?id=651837: "The correct way to receive Instant Messages is via the new OpalIMContext class. This will allow for future non-SIP IM to be used. For example, there are a lot of Jabber (XMPP) classes already in PTLib, one day in the not too distant future, I hope, we will bolt that into the OPAL system and there will be OpalPresentity and OpalIMContext derived concrete classes so the user application will barely change at all." 

Happy hacking,
Eugen


On 10/10/15 13:58, Damien Sandras wrote:

Hi Julien,
Thanks for getting back into this.
In SIP, I see two basic ways of having Chat sessions :
- Using the SIP MESSAGE request. It works like an SMS. You do not have
a notion of "conversation", you just send a simple text message
somewhere. That is what Ekiga supports until now.
- Using the MSRP protocol. It works like a "Text Call". You have a
notion of "conversation" between two peers and notifications indicating
that the remote is typing.
However, MSRP brings more features than simple text chat :
- File Transfer over MSRP
- Screen Sharing over MSRP
You also have extensions :
- Multi-participants chat rooms
- Conference information through the "conference-info" Event package
I think we should keep this in mind, but limit ourselves to 1-to-1
conversations for now.
Le vendredi 09 octobre 2015 à 18:18 +0200, Julien Puydt a écrit :

Hi,

I would like to help redesign the ekiga chat core. Of course, that
means
one should have a look at how text chat happens within various
protocols
beforehand.


With IRC (https://tools.ietf.org/html/rfc1459):

- you connect to a server, where you have a nickname, and the server
will send you messages (welcome, notices...) -- notice you can't
connect as the same nickname from different places simultaneously ;

- you can then join (and even create) a room [called a channel] where
you can see the list of members, each with some notion of presence
(away state), and a notion of role (voice, op). It can have a title
and you can get kicked or banned from a room, or invited to one ;

- you send messages to a single user, to a list of users or to a room
and as far as I know the server doesn't send you back your own
messages (so you have to note them yourself!) ;

- I don't think a one-to-one conversation is more than messages with
the same person (nickname, in fact) -- so there's no way to have
various conversations with the same person, and no way to turn a
one-to-one into a many-many one ; and also in a one-to-many I'm not
sure recipients know of each other, so they can't just reply to all.


With MSN (I haven't found decent&recent documentation):

- you connect to a server with an account, and you can connect to it
from several places ; I think you can have a nickname on the server ;
it's also where the contact list is ;

- you can then send one-to-one messages, or join/create rooms
(multiparty) ; I don't think you can have a room-specific nickname
and
I don't know if the server sends you your own messages ;

- I don't think a one-to-one conversation is more than messages with
the same person -- so again, no way to have various conversations
with
the same person ;

- I don't know if rooms have title, if there is special presence and
    roles.


With Jabber (http://xmpp.org/):

- you connect to a server, and you can connect to it from several
places
; it's
also where the contact list (named roster) is ; the presence exchange
is at
the server level ;

- you can send messages one-to-one or join/create a room. One-to-many
exists, but isn't natural (even with XEP-0033) ;

- the interesting thing about one-to-one is that you can either send
the messages in a one-off fashion or with a threading information
(see
5.1 in RFC 6121). In this case it's possible to have different
conversations with the same contact, and it's possible to turn a
private conversation into a group conversation, which others can join
(see section 7.9 of XEP-0045 - notice how the client is supposed to
send the history to the room) ;

- a chat room has a title, a list of occupants with their own
presence
(you might in fact not even know the "real identity" of the
occupants:
the nickname is per-room!) with roles ; it also has a history which
new joiners will receive.


With SIP: here I shall wait for a reply, as I'm definitely not
qualified
to discuss it at length.

I'm not sure I'm 100% right on all of the above: feedback is welcome!


Cheers,

Snark
[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]