[Serdev] SER as an extendable codebase/SIP stack - was: So who/what is SER for, anyway?

[Dragos Vingarzan]

>> 4. Because the CSCFs are just standard IETF SIP Proxies, on which 3GPP
>> recommends some usage patterns. it's not like 3GPP/IMS would reinvent
>> SIP proxies. They are just usage patterns and if you would look at the
>> RFC 4740, you would see the same architecture. If SER is a good SIP
>> proxy, it should also be a good CSCF.
>>   
> Yes, I see the arguments. I also see why you have had frustrations :-) 
> I'm not sure if SER "should also be a good CSCF" by virtue of being a
> good SIP proxy. Or maybe said differently: I think a more interesting
> question from a SER development perspective is: Should SER have a
> design/architecture that enables people to extend it with
> functionality like for example CSCF? And where do we stop before a
> good proxy has been turned into a bad "everything-for-all" ?
I hope that you are not saying that SER should be intentionally against
being CSCFs :)... because that would be too big of an effort to cripple
SER ;-).
>>>  * Would you use SER if you had to make the decision again?
>>>
>>>     
>> Unfortunately, NO. Because at this point there are certain easy features
>> that would take too much time to do them with SER than start over with a
>> new architecture. What keeps me to SER now is just it's stability and
>> the fact that a new base would be unstable for a long period of time
>> (too long for our academical and research-only purposes).
>>   
> Thanks for being honest :-)
Well, half of my response is good and half is bad. Taking the good part
- stability - I think that one is quite good.

And I have also realized why Martin is upset on my wave of change
requests: I was using 0.10.99 for a looong time now. For me it's old
news. And I am quite satisfied with it. The only outstanding thing that
I have might not be a bug. And having to fix one-two bugs every couple
of months is not bad at all. So, sorry guys, but I was kind of jumping
forwards and wanting a 0.11.99 :-P in the short term.

>> more internal APIs, better&transparent standard compliance, extend the
>> core with the most used ops in the modules
>>   
> I get the first one, the two last I'm a bit uncertain, but I'll pick
> it up in later posts and threads...\
standard compliance - would be nice to have some sanity checks on send
or something like that, if not more enforcement

extensions to the core - they don't really have to be in the core. just
that I want to rely on something. I am crying here for a bigger and
stronger base.
> I hope Martin has by now showed you that somebody would actually want
> that and why ?!
> g-)
well, he did. But I hope that SER's meaning is NOT to make stupid and
broken SIP clients barely usable. Because this flexibility is also very
dangerous and often SER+cfg is misbehaving after so many tweaking.

And again, there is a huge difference between me and Martin: it looks
like I am already bored with Ottendorf, while others just seen it's
power. I can leave with minor bugs, although the current version did not
gave me trouble at all. Sorry, I'll come back in 6 months :-).

-Dragos