Re: [Ekiga-devel-list] On rewriting the text chat stack
Le mardi 17 novembre 2015 à 17:13 +0100, Julien Puydt a écrit : > Hi, > > Le mardi 17 nov. 2015 à 11:18:16 (+0100), Eugen Dedu a écrit : > > Is this about the chat? If you could work on the chat, it would be > > excellent, as this is what we need now. We could let the emblems > > for later, > > once the chat is working. > > Well, I started to write some code. There needs three stages : > - an engine framework (abstract) ; > - an opal implementation (concrete) ; > - a GUI (concrete). > > I know what to write for the first stage, I have started reading the > opal code in ekiga to find out what to write for the second stage, > and I > have no clue yet for the third stage. I only saw there was no heap > widget... But for a first simple run, we can probably get away > without > it. > I think we used to have one. But at some point, I removed some unused code. I guess it was part of it. Of course, it can be reanimated at any time. But I also think we do not need it yet. -- Damien SANDRAS Ekiga Project http://www.ekiga.org___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] On rewriting the text chat stack
Hi, Le mardi 17 nov. 2015 à 11:18:16 (+0100), Eugen Dedu a écrit : > Is this about the chat? If you could work on the chat, it would be > excellent, as this is what we need now. We could let the emblems for later, > once the chat is working. Well, I started to write some code. There needs three stages : - an engine framework (abstract) ; - an opal implementation (concrete) ; - a GUI (concrete). I know what to write for the first stage, I have started reading the opal code in ekiga to find out what to write for the second stage, and I have no clue yet for the third stage. I only saw there was no heap widget... But for a first simple run, we can probably get away without it. It's slow, but I have my hands full... Snark ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] On rewriting the text chat stack
On 16/11/15 21:10, Julien Puydt wrote: Hi, Le 16/11/2015 10:58, Julien Puydt a écrit : Le 17/10/2015 23:20, Julien Puydt a écrit : Well, I'm still on the thinking side of things : writing comes later. I'm still thinking, but now also poking around ekiga's code to see what changed. I'm a bit annoyed I didn't find a heap-view widget, because I thought we had one and wanted to make good use of it :-/ I propose to extend the base Ekiga::Presentity class with this api call: virtual const std::list get_emblems () const = 0; The said emblems would appear in the GUI as little icons decorating the presentity and be used in the following use-cases : - in the main contact view, we could have information about how privileged the contact is (for example those able to call us even in do-not-disturb would have a star/heart shape in their emblems list) ; - in a chat room's heap view, the emblems could materialize people having voice or operator privileges ; - in chat room's heap view again, the is-composing feature could be just a "is-composing" emblem... Hi Julien, Is this about the chat? If you could work on the chat, it would be excellent, as this is what we need now. We could let the emblems for later, once the chat is working. Have a good day, -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] On rewriting the text chat stack
Hi, Le 16/11/2015 10:58, Julien Puydt a écrit : Le 17/10/2015 23:20, Julien Puydt a écrit : Well, I'm still on the thinking side of things : writing comes later. I'm still thinking, but now also poking around ekiga's code to see what changed. I'm a bit annoyed I didn't find a heap-view widget, because I thought we had one and wanted to make good use of it :-/ I propose to extend the base Ekiga::Presentity class with this api call: virtual const std::list get_emblems () const = 0; The said emblems would appear in the GUI as little icons decorating the presentity and be used in the following use-cases : - in the main contact view, we could have information about how privileged the contact is (for example those able to call us even in do-not-disturb would have a star/heart shape in their emblems list) ; - in a chat room's heap view, the emblems could materialize people having voice or operator privileges ; - in chat room's heap view again, the is-composing feature could be just a "is-composing" emblem... What do you think about it? Snark ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] On rewriting the text chat stack
Le 17/10/2015 23:20, Julien Puydt a écrit : Well, I'm still on the thinking side of things : writing comes later. I'm still thinking, but now also poking around ekiga's code to see what changed. I'm a bit annoyed I didn't find a heap-view widget, because I thought we had one and wanted to make good use of it :-/ Things aren't progressing nicely, but at least things move forward! Snark ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] On rewriting the text chat stack
On 17/10/15 23:20, Julien Puydt wrote: Hi, Le 16/10/2015 18:36, Eugen Dedu a écrit : 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. The goal isn't to implement all protocols -- it's to build things cleanly enough so it doesn't become a headache later. 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. Yes, one implementation, but the framework must be sound and not get in the way of a second. This is exactly the point I wanted to address. I see that you do not agree with me, but I think it is better for Ekiga project to implement ONE protocol/framework as fast and simple as possible, and only when you or someone else wants to implement another protocol, change the code/framework so that both can coexist gracefully. Of course, if the code/framework has almost the same complexity (e.g. 10 lines more and no additional class/variable), then it is fine to think at a global framework right now. But, after reading characteristics of the protocols you cited, I see that they are too different (one to one / one to many, create rooms or not, nickname / account, room titles or not, presence, history etc.) To resume, I suggest to implement something functional in a short time, instead of having a currently-good global framework with a more complex code and only one implementation and which takes more time. -- Eugen ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] On rewriting the text chat stack
Le samedi 17 octobre 2015 à 23:20 +0200, Julien Puydt a écrit : > > 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... > > Well, GUI isn't my strong point, but I think having the text in a > window > and the fact of the other person in another is pretty inconvenient, > so > there should be a way to put both side-to-side. > On the other hand, I think you are not supposed to have text and video at the same time. You will probably discuss using text chat before initiating a video call, and most of the time, the video call will go full screen. >From my point of view, I would keep them in separate windows for now. It is >also less work. -- Damien SANDRAS Ekiga Project http://www.ekiga.org___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
Re: [Ekiga-devel-list] On rewriting the text chat stack
Hi, Le 16/10/2015 18:36, Eugen Dedu a écrit : Thanks, Julien, if you could implement the chat, right now it is the only important regression I think (compared to v4). In which chat was pretty bad... 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. The goal isn't to implement all protocols -- it's to build things cleanly enough so it doesn't become a headache later. 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. Yes, one implementation, but the framework must be sound and not get in the way of a second. 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. Yes. 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... Well, GUI isn't my strong point, but I think having the text in a window and the fact of the other person in another is pretty inconvenient, so there should be a way to put both side-to-side. 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." That's a good thing to have in mind for the one implementation, thanks for the reminder. And it can help to see how things are organised there. I'm also having a look at pidgin's sources. Happy hacking, Well, I'm still on the thinking side of things : writing comes later. Snark ___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
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
Re: [Ekiga-devel-list] On rewriting the text chat stack
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 > ___ > ekiga-devel-list mailing list > ekiga-devel-list@gnome.org > https://mail.gnome.org/mailman/listinfo/ekiga-devel-list -- Damien SANDRAS Ekiga Project http://www.ekiga.org___ ekiga-devel-list mailing list ekiga-devel-list@gnome.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list
