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.
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.
Well, I'm still on the thinking side of things : writing comes later. Snark _______________________________________________ ekiga-devel-list mailing list firstname.lastname@example.org https://mail.gnome.org/mailman/listinfo/ekiga-devel-list