It is important to not violate scope. Do not let one problem define your path. The goal is not to make the default a certain way. The goal is to scale from static configs to dynamic as seamlessly as possible. On May 14, 2011 4:20 AM, "Mathieu Parent" <math.parent@gmail.com> wrote:
2011/5/10 Rupa Schomaker <rupa@rupa.com>:
On Tue, May 10, 2011 at 3:19 PM, Mathieu Parent <math.parent@gmail.com> wrote:
I have doubt about mod_hash because it doesn't propagate hashes on remote servers (it does for limits only). Should I use mod_db instead?
+1
Thinking wider, what we need is an updatable directory. The directory is by default stored as readonly XML files. Mod_voicemail currently workaround this (IMO) by creating an SQL table to store vm password. Couldn't we provide a more generic handler ?
Proposal: add a new xml_int binding: "directory_update". -------------
With mod_xml_curl, the POST request will look like this:
[hostname] => testmachine [section] => directory_update [tag_name] => domain [key_name] => name [key_value] => domain1.awesomevoipdomain.faketld [key] => id [user] => 1004 [domain] => domain1.awesomevoipdomain.faketld [set-param-forward-all-destination] => 1234 [set-param-forward-all-status] => 1
(POST variables prefixed with "set-param-" or "set-variable-" modify the relevant XML attribute)
The xml_int should return either: <?xml version="1.0" encoding="UTF-8" standalone="no"?> <document type="freeswitch/xml"> <section name="result"> <result status="success" /> </section> </document> or <?xml version="1.0" encoding="UTF-8" standalone="no"?> <document type="freeswitch/xml"> <section name="result"> <result status="not found" /> </section> </document>
A new function is needed: SWITCH_DECLARE(switch_status_t) switch_xml_update_user(const char *key,
const char *user_name,
const char *domain_name,
switch_event_t *params)
Where params is an event containing the set-* variables.
As mod_xml_curl is not configured by default, we need something to update XML files: any idea?
I will start to implement the suggested proposal.
-- Mathieu
_______________________________________________ FreeSWITCH-dev mailing list FreeSWITCH-dev@lists.freeswitch.org http://lists.freeswitch.org/mailman/listinfo/freeswitch-dev UNSUBSCRIBE:http://lists.freeswitch.org/mailman/options/freeswitch-dev http://www.freeswitch.org