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

[Klaus Darilion]

Hi Andrei!

Andrei Pelinescu-Onciul wrote:
> On Nov 22, 2006 at 12:39, Klaus Darilion <klaus.mailinglists at pernau.at> wrote:
> [...]
>>> I'm being told that some other personal affiliated with
>>> the same company more or less copied-n-pasted TCP code from the allegibly
>>> discontinued SER to OpenSER.
>> That's how open source works. I also copied lots of TLS extensions from 
>> ser to openser, and even extended it. You can also copy my extensions 
>> back to ser ... I would love to see it there :-)
> 
> 
> I'm sure Jiri has no problem with copying code from ser to openser.
> We will do the same with some openser modules and we already did with
>  some fixes.
> The problem here was that it was claimed that ser was dead but in the
> same time new code commited in ser was added in openser (so the
>  openser history writer was not very well intended).

As I already said (maybe to less explicit) this is obviously false and 
should be fixed.

> Speaking of copying/porting ser between ser and openser I have a few
>  requests:
> 
> 1. If someone sends a fix for code taken from ser, which was not
> modified in openser, please could you also bounce the message to the ser
> maintainer of that piece of code? If you don't to whom, just send it to me
> and I will make sure it reaches the right person.
> I'm asking this because my favourite pass-time is not to scan openser
> commitlogs for possible fixes to my code 
> (e.g.:http://openser.cvs.sourceforge.net/openser/sip-server/fastlock.h?r1=1.2&r2=1.3)
> and this will help me at a minimum effort for the openser developer
> part. Of course I think this is true not only for me, but also for other
> ser and openser developers and I (and I'm sure anybody else on the ser
> team) will return the favour.

This is a practice which must be done by the core developers. I often 
see bug fixes, but for me it is impossible to know if the fixes are for 
original ser code or for new code. In the beginning I watched the ser's 
CVS commits and forwarded fixes to the openser list. Some of them were 
applied to openser too, but not all of them.

I agree it would be nice if the core developers exchange fixes for 
common code - maybe a common mailing list would help for this?

> 2. Please give proper credits for the code you port from ser.
> I've saw several times things like: Foo sees something was fixed in ser
> or a new small feature was added and sends an email to the openser list
> (specifying that the change/patch comes form ser).
> The openser developers take the change, but the commit message says
> something like: fix for XyZ, credits go to Foo (ser is not mentioned at
> all).
> It would not only be polite, but it will also help us to filter more
> easily through the openser fixes.

I agree - it should be explicitly mentioned when a patch comes from ser.

> Comming back to the openser - ser performance / features discussion, I
> think the important part here is how we can improve both sers
> (and you should take the test results as a bug report and maybe ask
> yourself how did this go through testing, even old sers were faster
>  then 4000 cps). 

You think the current openser has a bug because of the low performance?
In this case it would be interesting to see how stable ser (0.9.x) 
compares to openser - if there is really a loss of speed in openser's tm 
module compared to its roots (ser 0.9)

> If you think only of the users, then a combination of ser & openser will
> be the best version.

Of course - I was not happy about the split because it was clear that 
some features will be only in one of the two branches.

 > While we disagree (probably) in many respects, I
> think there are at least a few clear advantages each version has.
> For example openser has very impressive documentation (at this time 
> ser is very far away from this point of view) and lots of new modules.

I agree - that's one of the reasons I prefer using openser also in new 
installations.

I still wonder why you do not the same. Autogenerate the README files 
from the xml files and put them on the webpage - this is what openser 
did (and some improving of the README).

You started a wiki which must be filled - thus you are starting from 
ground although there is already lots of documentation in the READMEs.

Further, I often see commits in ser with new features but without 
documentation. In openser it is not allowed to introduce new features 
without writing a documentation patch. Why isn't there the same rule in 
ser?

> ser has also its share of new modules (though I think not so many) and a
> better/improved "infrastructure"  (core, tm and lots of the "base"
> modules - we are actively improving them). ser code tends to also be
> more tested and stable (our release policies differ wildly).

Probably faster release cycles does not allow such heavy testing as you 
do - nevertheless openser1.0 was real heavy tested (by me).

> I've tried looking at openser core & tm commits and I haven't seen any
> significant changes (and this is not a flamewar attempt).

Aren't the pseudo variables vs. select framework significant changes? 
Also TLS in core vs. TLS as module?

> Now the question is why doesn't openser take the core, tm and a big
> part of the modules from ser completely and concentrate then in adding
> new modules (which you seem to do anyway)? Does it make sense to
> re-invent the wheel ?

I would like to see that too - although I sometimes commit code I am 
rather a user than a developer and of course I would like to benefit 
from all the new features in ser and openser.

Probably it is a matter of time. Replacing openser's core is sure lot of 
work. And maybe it is done if openser's core/tm will become a bottleneck.

> Everybody (me too) suffers at least a little from the not-invented-here
> syndrome, but if you think of the users and at how much of your time it
> will save, it will make a lot of sense, even if some compromises would
> be necessary.
> I think the advantages will far outweigh the problems. Just think about
> it, we can concentrate each other on our favourite stuff and we can
> benefit much more easily from each other's work.

I'm completely with you - but this is something the developers have to 
agree - not the users (me).

regards
klaus

-- 
Klaus Darilion
nic.at