[asterisk-dev] pipes, comas and defaults [was: Asterisk 1.6 Realtime Database must use ', ' not '|' in appdata field?]

[Russell Bryant]

Tzafrir Cohen wrote:
> 1.8? 1.6.1? 1.6.2?

1.8, or 1.6.alongtimefromnow ...

> BTW: one difference between the impact of this change on RealTime and on
> extensions.conf:
> 
> In real-time you previously had to use a pipe. After the change you have
> to use a comma. There is no way to have the same dialplan used for two
> Asterisk instances with different settings.
> 
> With extensions.conf the migration path is to convert everything to
> commas. This should work well with any modestly-recent Asterisk version.
> Requires a change: yes. But after you did the change you can still go
> back and use your old system.
> 
> Or, after you converted your dialplan-writing program to use commas, you
> can use it with all versions of Asterisk. But with RealTime you have to
> know in advance the type of Asterisk that will use the database.

Good point.  Hopefully the compat14 option addresses that concern.

> I don't like adding yet another case where the "recommended
> configuration" (as manifested in the huge sample configuration,
> something that too many of the people will never bother reading) 
> is different than the default.
> 
> (This is why I wrote before that a compatibility mode is a great
> solution for an individual, but leaves you in the dry when you're a
> distributor and have to set a certain deault)
> 
> For instance, here are a number of questions an inexperienced user might
> ask himself after reading the sample configurations:
> 
> * If I write my own modules.conf, what is the default of "autoload" in the
>   section [modules]?
> * In sip.conf, if I don't write context=default, will calls go to an
>   empty context?
> * What is wrong with overlap sip dialing that the sample config file
>   disables it?
> * What happens if I don't write explicitly "bindport" and "bindaddr"?

I can certainly agree that the sample configuration files could be improved by 
leaps and bounds in many ways.

> In short: if a configration option is enabled in the sample config file,
> why is it not the default?

It's the difference between a default value for backwards compatibility, and 
default configuration for new installations.

> A bit further down that file:
> 
>   tcpenable=yes  ; Enable server for incoming TCP connections (default is yes)
> 
> Now suppose that in the Asterisk 1.6.1 cycle we find that SIP/TCP is a
> horrible thing and nobody does it right, and hence it should be disabled
> by default. How many installations will be left with that obsolete and
> bad settings after they upgrade?

That's a pretty bizarre hypothetical scenario, given that TCP support is 
"required" in RFC 3261.  :)

However, I see your underlying point.  I think you're basically asking whether 
it makes sense to have sample configuration set _any_ options.  In my opinion, I 
think it does make sense for the reasons I said before.  In the past, we have 
used it for setting recommended values for new installs, while the in-the-code 
default is different for compatibility reasons.  It's all about trying to create 
the smoothest transition path we can ...

> We can always blame them later for not bothering to read the CHANGES
> file upon upgrading. But it's more effective to avoid the issue
> beforehand.
> 
> Furthermore, if I need to put a default configuration for my package,
> what should I put? The compile-time defaults or the sample ones?

The sample ones, IMO.

-- 
Russell Bryant
Senior Software Engineer
Open Source Team Lead
Digium, Inc.