Use mod xml curl for dialplan and directory

[GoogleCodeExporter]

Instead of regenerating static xml files it would be nice to use the webserver 
to generate a dynamic xml file so that FreeSWITCH could use mod xml curl for 
configuration.  A distributed platform could then be built using a shared 
database that would provide high availability and scalability.  FusionPBX could 
reside on a configuration node and then 1-N worker nodes could be added as 
needed.  Also this would solve the conflicts with the example configs.

Original issue reported on code.google.com by sjthomas...@gmail.com on 9 Nov 2011 at 6:51

[GoogleCodeExporter]

XML Curl is nice for some things, just like static xml configs are nice for 
some things. Both have pros and cons.

[Static XML]
Pros: 
- Fast method available. Reloadxml loads the configs into RAM where they run 
faster than any other option.
- The least number of points of failure and dependencies.
-Easy to Modify the configs to work the way you want when the need arises. Make 
a file with the FusionPBX rename it and remove the v_ then remove it from the 
GUI and you can now manage it manually for whatever special requirement that is 
needed.
-Still allows XML CURL to be used where desired.

Cons: 
- Reloadxml starts to get a little slow when there are over 10,000 or more 
extensions or dialplan entries. This can be fixed by FusionPBX automatically 
combining the extensions and dialplans into larger files for installs with a 
huge number of extensions or dialplan entries or by putting the configs on a 
fast drive or ram drive.
- Distribute the files across multiple machines can be done with rsync or 
something similar since you already have to do this for voicemails it is not 
much more work to do this for the script and conf dir.

Nuetral:
- Rsync can be used to distribute the configs across multiple machines you 
already need to do this or something like it to copy the voicemail recordings.
- Some additional work could be done to push changes to notify remote servers 
to re-sync the filesystem as changes occur.

[XML Curl]
Pros:
- Flexible in changing the configs on demand as things change which is useful 
in certain situations.
- Reloaxml isn't needed for features that support XML Curl.

Cons:
- More dependencies and points of failure.
- Slower to deliver configs.
- Developers control access to features
- More system resources are required.
- XML Curl doesn't work with all of the FreeSWITCH modules
- Not as Easy to Modify XML curl based features requires programming unlike the 
XML configs which just requires some reading the wiki or book and a little 
patience to the admin makes it do what their special need requires.

Nuetral:
- Scalability scales as the web server and database servers are scaled.
- Easy to distribute but you don't escape the need to use rsync or something 
similar because you still need to copy recordings, and voicemails to the other 
servers.

[My Point]
I'm sure this is not a complete list for both of these methods. But my point is 
that there are pros and cons to both methods.

[Option to use XML Curl]
I believe in choices and do plan on offering XML Curl as an option available. 
In fact there are some people that use it for on their FusionPBX systems.

[Example Configs]
Conflicts with example configs will go away when the install makes a backup of 
what is there and then installs a set of configs that are based on the 
FreeSWITCH defaults but improved and supplied by the FusionPBX install.

Original comment by markjcrane@gmail.com on 9 Nov 2011 at 8:40

• Added labels: Type-Other

[GoogleCodeExporter]

[XML Curl]
Cons: Not all FreeSWITCH modules are XML Curl compatible.

Original comment by markjcrane@gmail.com on 19 Nov 2011 at 3:42

[GoogleCodeExporter]

[XML Curl]
Cons: More security exposure since the configs are delivered to FreeSWITCH 
through the network, web server and database server.

[Direct to the Database]
Pros: 
- Less dependencies than XML Curl
- Easy to distribute over multiple servers

Cons:
- Less flexible than XML Curl. While this is not a problem for some features it 
may hinder others. However when using this method XML Curl, or Scripting are 
still an option to provide the flexibility when needed. 

Original comment by markjcrane@gmail.com on 29 Nov 2011 at 11:58

• Changed state: Accepted

[GoogleCodeExporter]

Progress Report

I have succeeded in getting a method working for registering phones that goes 
'Direct to the Database'. This approach removes the web server as a dependency 
and I believe is the more efficient choice. Hope to add ability to do this for 
the dialplan and sip profiles in the near future.

Original comment by markjcrane@gmail.com on 24 Apr 2012 at 1:39

• Added labels: Type-Enhancement
• Removed labels: Type-Other

[GoogleCodeExporter]

Added memcache to make the direct to database approach more efficient.

Original comment by markjcrane@gmail.com on 8 Dec 2012 at 8:56

[GoogleCodeExporter]

'Direct to the Database' as of FusionPBX 3.3 can do the directory (extensions), 
dialplan (time conditions, inbound/outbound routes), sip profiles, gateways and 
more. And has been proven in production to work with hundreds of tenants.

Original comment by markjcrane@gmail.com on 27 Jul 2013 at 4:24

• Changed state: Done

[GoogleCodeExporter]

Can anyone guide me on how to dynamically create extensions with xmlCurl from 
.Net framework?

Original comment by ne...@aceast.com on 10 Dec 2013 at 4:48