On Mar 22, 2006, at 6:49 PM, opus wrote:
Well, since you have asked ... You are missing the point of the meta dialplan concept where you don't have to settle for a single engine, where nobody is forced to use someone else's pet language if they don't want to, where language engines compete for uptake on their merits alone. If you want to suggest a single engine then this is precisely what you are doing, btw, forcing your pet language on anybody else. Also, having a variety of plug-ins serves a purpose as a sandbox for various dialplan engines. It is rather folly to make a decision what language to use based on how comfortable you are with your pet language. The approach should be to try out different engines and see how it all goes. Who says that one single language is suitable in all situations anyway? If I ask you which is the better vehicle, a Porsche 911 sports car or a Komatsu 930 mining truck, you may pick the Porsche, because you fancy a joy ride, yet for running a mining business, the Porsche is pretty useless. There is a reason why there isn't a one-size-fits-all-needs product, no matter where you look. Those who claim to have one are usually selling a mediocre product. It is also rather questionable to say "this is how much scalability I think I will need, hence nobody else should need to scale beyond that either". For example, the Erlang based webserver "Yaws" outperforms Apache by several orders of magnitude thanks to Erlang's underlying concurrency model. Now, just because your Apache server doesn't top out, doesn't mean there aren't any folks who don't need a webserver that goes far beyond your scalability requirements. BTW, the Io language is not a descendent of Erlang nor otherwise related, it only happens to use the same concurrency model, which happens to be the overriding-all-else concern for scalable high performance telephony servers/switches. Unlike Erlang, Io is well suited for embedding. For embedded uses, a special stripped down version of Erlang is under development, which goes to show its not so well suited for embedding. However, if somebody has the time, the skill and the will to write an Erlang plug-in engine, I'd welcome that, too and I would like us to play with that and see how it fares. It just seems that due to its small size, it is far less effort to write an Io plug-in than one for Erlang. As far as JSON is concerned, it would forfeit all the objectives that led to the plist support effort if we switched to that. The syntax of the configuration files is only a detail, not the main driver. The main benefit of the plist system is not the syntax (although its clean syntax alone may be deemed a reason to use it over INI file format) but the cascading domain level structure which will be very useful in cluster environments and also the fact that we get XML as a side effect without having to pay for it and without creating incompatibilities between installations whose system admins prefer XML and those whose system admins prefer plaintext. regards benjk |
_______________________________________________ Openpbx-dev mailing list [email protected] http://lists.openpbx.org/mailman/listinfo/openpbx-dev
