That's very clumsy, complicated and confusing way of doing something that ought to be simple!
Hello Will,
Heres the long answer
Keys are allocated as meaningless unique digit strings in keeping with Boyce-Codd entity integrity. Semantics, even convenient ones, should not be allocated to primary keys. Furthermore, we do not want to complicate the mainline with decision making code based upon any semantic constructs mapped onto number series, particularly any of range or form.
SAIL is about speed and economy of execution. Nothing else (and we've benchmarked 'em all) comes even close to us on path length and economy of resource at run time. However we DO have to handle the need for short "feature key" sequences such as CFIM, CFBS etc etc. In an earlier post you referred to us being free to challenge traditional ways of doing telephony. Well that's true but not at the risk of steepening the end-client's learning curve. PBX users are accustomed to the switches working in a certain way (probably with Definity being the World Wide dejour standard) and we would only challenge that if we felt there were very large gains to be made.
Aliasing allows us to give the SOHO user a simple semantic mapping which is indistinguishable to them from a real extension. It also runs blindingy quickly because it involves a single in-memory foreign-key/primary match.
The key structure gives us unlimited headroom without compromise so we can handle a system from 2 phones to 20000 and beyond (given enough resource) without system change. The 4-digit limit is purely front-end. The back-end recognises no such limit. It also recognises that traditional PBX's use *nn and shortcodes for system commands and users are used to that and comfortable with it.
With SAIL, we are absolutely obsessed with two things; speed of execution at run-time and regressable, manageable code. None of the other asterisk generators can demonstrate either of these things today and that's why we believe SME/SAIL is the ONLY (strike that - Bicom is also very close although it doesn't install/de-install as competently as we do) credible production-capable asterisk workbench out there right now.
On the issue of manageable code (which you didn't raise but is part of the overall answer), the acid test has to be this. - Can you regress a new release easily and quickly if it fails? Because if you can't then you better have shit hot lawyers or a very fast car. Customers will tolerate an on-line system being down for hours or even a day or two in some circumstances. Try taking away their phones for even a few minutes and you'll very quickly grasp the legal concept of liquidated damages.
We've sweated blood on SAIL and Asterisk itself, bringing the packaging, distribution and performance to a level where it can safely be distributed to none-technical end-customers. We won't compromise that with number series management or anything else which dilutes the underlying simplicity and purity of the mainline.
I'll get off me soap box now.
Best
57 Replies
17474 Views