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

[Tzafrir Cohen]

On Wed, May 28, 2008 at 06:20:11PM -0500, Russell Bryant wrote:
> 
> On May 28, 2008, at 5:24 PM, Steve Totaro wrote:
> > To me the "Magic Balance" is quite simple.
> >
> > I say stick to the method of change that has been done and accepted
> > widely by everyone, users and developers.
> >
> > Throw warnings of deprecation in 1.6 and then make the full change  
> > in 1.8.

1.8? 1.6.1? 1.6.2?

> >
> > Everyone has been following that since the beginning and happily
> > discuss on the Users list how to go about it with no real complaining.
> >
> > Why make radical changes without a phase in period?
> >
> > "It is Just That Simple" (tm)
> 
> I certainly had the understanding that the comma was the preferred  
> delimiter for a long time.  However, it is quite possible, and even  
> likely that it was not documented well enough, or deprecated in an  
> obvious enough way in 1.2 or 1.4.
> 
> If that is the case, I wonder if we could add a compatibility mode for  
> all argument processing, in the same spirit that Tilghman added the  
> option for realtime extensions.  I don't think that it would be _too_  
> hard to implement.
> 
> Furthermore, I would say have the compatibility mode enabled by  
> default.  However, I would set the option to turn it off in the sample  
> configuration, so that any new installations have it off with the  
> default set of configuration.

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.

> 
> Is that a reasonable compromise?

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

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

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?

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?

-- 
               Tzafrir Cohen
icq#16849755              jabber:tzafrir.cohen at xorcom.com
+972-50-7952406           mailto:tzafrir.cohen at xorcom.com
http://www.xorcom.com  iax:guest at local.xorcom.com/tzafrir