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

[Jan Janak]

Dragos Vingarzan wrote:
> 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.

  I don't know if it is a good solution but I cannot currently think of
  a better one. Note that all the hacks, as you call it, have been there
  because someone needed them, it's not that we were trying to make the
  configuration file too complicated or flexible by intention.

  On the other hand it is true that some module functions or parameters
  need re-thinking because they are hard to use in the script.

    Jan.

> 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
>