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

[Eugen Dedu <eugen dedu univ-fcomte fr>]

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