[Serdev] SER's core design features(process model/parser/lumps/script) - was: So who/what is SER for, anyway?

[Dragos Vingarzan]

Jan Janak wrote:
> Klaus Darilion wrote:
>   
>> ...
>> rtp_proxy=mediaproxy/rtpproxy
>>
>> allow_preloaded_routesets=no/yes
>>
>> And so on. 
>>     
>
>   But this is how, for example, asterisk works. I have seen a couple of
>   setups where the default behavior of nat traversal as you described it
>   was not sufficient and I had to do custom changes -- being grateful
>   for the flexibility we have.
>
>   
OK, but what if when you discover a strange behavior you put it in and
then have a flag, like "fix_the_stupid_X_nat". This flag being
documented, would then save a lot of time for a lot of administrators
that would bang their heads on the same X NAT. But having all these
hacks here and there and having to put them in all other routes that do
something completely different is just too hard to be a good solution.
It's like the tm module - great that maybe it gives lots of power to the
chosen ones that got it, but what about the rest? Is it their fault?
>> PS: We could start with a script which generates the ser config from a
>> template file and a user configuration file as starting point for users
>> (like the exim4 configuration in debian)
>>     
>
>   Yes, I think something like this is the right way to go. In addition
>   to that we could use external configuration files for modules (such as
>   the one for tls module) and the possibility to include other files in
>   the configuration file.
>
>     Jan.
>   
This sounds like a leveled script, but just more complicated. I think
that we should not mix apples with oranges in the script if we want it
to still be understandable by a human being.

-Dragos