[asterisk-users] Using existing extensions.conf macros, and co-habitation

[Philip Prindeville]

Anthony Francis wrote:
> Philip Prindeville wrote:
>   
>> Tilghman Lesher wrote:
>>   
>>     
>>> On Thursday 29 November 2007 13:29:17 Philip Prindeville wrote:
>>>   
>>>     
>>>       
>>>> [snip]
>>>> The issue is that I have, per "virtual pbx" (i.e. home or business), two
>>>> contexts that these get used from.  The "internal-xyzzy" and
>>>> "incoming-xyzzy" contexts (one for each pbx, ie. "xyzzy" is "home" or else
>>>> it's "office").
>>>>
>>>> I was wondering if there wasn't a more flexible solution to this issue,
>>>> than hard-coding a "Goto(default,s,1)" into them (I have no default
>>>> context, because it would be meaningless).
>>>>
>>>> Perhaps using "Gosub" and "Return".  Or do I need to hack the macro, and
>>>> pass in a 3rd argument (bletch)?
>>>>     
>>>>       
>>>>         
>>> MacroExit or Gosub/Return would certainly be possibilities.
>>>
>>> The main thing to note is that this macro that you call standard is actually
>>> just an arbitrary example.  It is by no means perfect, so feel free to adapt
>>> it to your own liking.
>>>   
>>>     
>>>       
>> Sure.  I just figured that it would be nice if the canned macros worked 
>> out-of-the-box without modification, in the real world.
>>
>> I suppose I could file a bug, and then submit patches for the macro and 
>> documentation...
>>
>> -Philip
>>
>>     
> The ability to modify the macros to your own needs is not a bug. Anyway 
> try adding a few more args to your stdexten to handle the context name 
> and the like so it doesn't need default. On another point, why would 
> asterisk come with built in code example for a multi-tenant set-up? 
> Please save your self some time and embarrassment by not submitting that 
> particular "bug".
>
> Anthony
>   

Using the "default" context is a bad idea, as is pointed out in several 
places (including the SECURITY document, the O'Reilly book, and several 
good online tutorials).

Besides, what's the point of having all the flexibility that you have in 
Asterisk if you're going to shoot yourself in the foot by having canned 
macros that limit that flexibility?

Let's say I file the bug, and someone closes it.  What's the harm?  
Someone doing a search of the database will at least later have the 
suggested patch as a possible resolution to their trying to address the 
same or a similar requirement.

Good thing I'm not easily embarrassed, or I'd find your attitude stifling.

And to address your question:  it wouldn't be code *for* multi-tenant.  
It would be code that *didn't preclude* multi-tenant.

Anything worth doing is worth doing right.

Examples provided with Asterisk should showcase its power and 
flexibility.  Not limit/ignore it.

-Philip