[Serusers] Re: [Users] TM : retransmission timers

[Jiri Kuthan]

[everything else above snipped -- I just got intrigued by this]

At 12:19 30/11/2006, Andrei Pelinescu-Onciul wrote:
>In fact even if we can't reach an agreement in dividing areas, small
>cooperation like on fixing/improving code that is the same in both
>versions would still be good.
>I would say that even a friendly competing approach would be better then
>nothing (with comparisons, benchmarks a.s.o), it points out problems in
>both versions and serves as a motivation to improve.

I think this is really the point. I haven't commented on the fork before
but I argue that if folks want to have advantage of that (and to be clear
I don't dispute openser advantages, among others documentation is
marvellous), there should be damage control in place to compensate the 
disadvantages. Presumably because many folks perceive this (not without 
a reason) as a contraversial topic, I have received quite some feedback 
in privacy and it is too what I personally think: split development 
does split results. openser folks may correct me if I'm wrong, but openser 
has not undergone an overhaul like we did (timers, DNS, STUN, DB, etc etc) 
with ottendorf which means some parts do not appear to be state-of-the-art.
Again: I'm sure that openser folks working hard may be upset about this
statement, but in the end it is not meant to devalue anyone's work --
I'm saying the maths is easy -- some folks were focusing on DNS and made it 
better, some on XMPP and made XMPP better.

I better don't speak for Andrei to avoid any possible misinterpretations,
but I think the alternaves he has offered are very reasonable. Labor
division, coordination of fixes, friendly progress-stimulating competition,
all of that are things which can make results better.

I'm just curious what the openser-oriented answers will be. I mean
no answer is in a sense answer too, but I'm still wondering if I could
get something more explicit. 

We will definitely be contributing to the synergies in some or other ways.


-jiri


--
Jiri Kuthan            http://iptel.org/~jiri/