[Serdev] SER architectural decisions - was: So who/what is SER for, anyway?

[Jiri Kuthan]

At 13:07 25/01/2007, Dragos Vingarzan wrote:
>Olle E Johansson wrote:
>> Well, the same can be said for Asterisk. It's a problem with Open
>> Source, that
>> it keeps growing, hacks are laid on top of other hacks and there's a
>> shortage of resources for a re-start. In some cases, it happens through a
>> fork, in some cases within the project - like Apache or JabberD.
>
>Yes, this happens a lot, but when there is a clear and independent
>leader, maybe he could push big changes, cut branches, create new ones,
>etc. When there are many, some of them would certainly have other
>interests and would want to keep the current tree as it is. Why break
>something that works just fine for some, right? But my impression is
>that too many core developers are just happy with SER and its position
>now to accept something really new, like a direction change.
> Maybe some
>developers are too afraid that the new version would not be accepted and
>used by the community if at the beginning it won't be on the par with
>the old one... Am I wrong?

I think so. I can speak of myself and prefer to change proven things if
there is a worthy objective and solid problem statement. L’art pour l’art 
is not my thing. Or perhaps for your purpose something completely else
than SER would be better adequate...


>But hey, what is the great thing in having a free proxy so optimized
>that can handle millions of users with the costs of a normal server?

Size matters. Once you get hands on some reasonably size deployment, 
you will figure out that there are so many abnormal situations on the public 
Internet  every day, that a performance buffer will conveniently save you 
lot of hard time and many boxes and salaries for their admins. 

> So
>that you can save money and then invest it into doing a lot of efforts
>for replicating states and assuring something close to 99.999%? I think
>that this replication and carrier-grade feature should be in the core if
>the core handles so many cps, or else the numbers are totally
>irrelevant. So this is something else that I am not happy about related
>to the architecture - reliability is provided by users and it is often
>hidden from others (although some "best practices" surface from time to
>time).

That's not about putting in the core which is on purpose lean. The missing
piece is publishinhg BCPs.

-jiri


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