[Serdev] usrloc loading

Greger V. Teigre greger at teigre.com
Wed Jan 24 16:13:52 UTC 2007


Well, what I feared happened. :-(

I did not approve of Bogdan's post because I saw it as out-of-topic (who 
ser should be for was the topic, not openser), as well as not welcome 
because of the not-so-friendly relationship between the two developer 
groups and because I interpreted the post as yet another stupid ser vs 
openser discussion.

That being said and harm already done, Martin answered on topic and 
Bogdan's reply was the same, and also balanced and polite.

However, for the other posts..., escalating this with sarcastic replies 
make people from the ser-camp no better. I hoped for better, but feared it.

I'll try to learn from it and will from now on not reply or participate 
in threads that do not follow basic guidelines of: treat the other as a 
human, stay on topic, and don't create a ser vs openser discussion.

To Bogdan: If you in the future feel that I have misrepresented openser 
in same way, due to ignorance or otherwise, feel free to drop me a 
private note, and I will promise that I will listen and if not 
automatically correct my statements on the lists, at least learn and 
adjust my perspectives.

It is still my opinion that the fork was the responsibility of both 
camps, that it should not have happened, and that both projects will 
benefit from cooperating. ser/openser have powerful competitors and both 
projects may very well end up as a parenthesis in the SIP history unless 
attitudes are changed.

Greger

Greger V. Teigre wrote:
> Hi Bogdan,
> This was an element in a discussion about ser, not openser. I'm not 
> interested in having a discussion about openser on serdev beyond 
> comparisons that may set ser in some perspective, and I find your 
> interruption quite tedious and self-centered. However, if you have 
> opinions about ser that are relevant to the discussion, you are 
> welcome to join.
>
> If you reread my post, you will see that my argument is that both ser 
> and openser make it too easy too create ser.cfgs that break the RFC. 
> Quite far from how you read it.
>
> Previous openser/ser discussions on serusers and serdev have not been 
> very fruitful, ex. the performance discussions. If you want a dialog 
> for the benefit of users or joint development work, feel free to make 
> a proposal, but please refrain from self-righteous posts on serusers 
> and serdev. You should allow SER users and developers to discuss ser 
> from all sorts of perspectives without disturbing with your agenda. 
> This is a privilege I believe the openser community enjoys on the 
> openser lists.
>
> Considering that your historical default response in discussions is to 
> state your opinion and then be silent, I assume this discussion is dead.
>
> Regards,
> Greger
>
> Bogdan-Andrei Iancu wrote:
>> Hi Greger,
>>
>> OpenSER does not "pretend" to be everything to everybody, but tries 
>> as much as possible to respond to the user's feedback (reports, 
>> needs, etc).
>>
>> I know it is your HO, but can you be more specific (just list one or 
>> two cases maybe) where you think OpenSER breaks RFCs?? I always 
>> though that backing up with facts puts more strength in words.
>>
>> actually being RFC-compliant is one of the top requirements we have 
>> as project and a lot of effort was put in this direction (RFC3261 - 
>> correct via building, RFC3263 - complete algh implementation for 
>> server discovery, etc)
>>
>> regards,
>> bogdan
>>
>> Greger V. Teigre wrote:
>>
>>> :-) In fact, to me, OpenSER seems to pretend that it is all things 
>>> to all people. That may work for a while (and in fact, maybe we 
>>> should send some people to OpenSER...) IMHO, it seems that OpenSER 
>>> is going in the opposite direction of SER by introducing all sorts 
>>> of "special case" functionality that confuses people and allows them 
>>> to break more parts of the RFCs.
>>
>>
>>
> _______________________________________________
> Serdev mailing list
> Serdev at lists.iptel.org
> http://lists.iptel.org/mailman/listinfo/serdev
>
>


More information about the Serdev mailing list