Hi all, I'd like to generate user directory xml directly in FS to bypass http +php (or other scripting language) entirely. So I started writing a module to do just that. It's still rough - I don't code c very often - but it works. http://jira.freeswitch.org/browse/XML-3 Currently all queries are statically defined in the module so users cannot deviate from the sql schema. Bkw suggested to have a look at mod_lcr which look really cool, though I'm not really sure yet how to get the same behavior in this module. The sql schema (without indexes for readability) currently looks like this: http://pastebin.freeswitch.org/9427 In the module, I'm doing 7 queries: Q1: Get domain_id and user_id Q2: Get domain_params Q3: Get domain_variables Q4: Get user_attrs Q5: Get user_params Q6: Get user_variables Q7: Get groups Where Q2-Q6 should return a list of name/value pairs. To make things more configurable by the user of the module, I could place all queries in the configuration file, like this: http://pastebin.freeswitch.org/9426 Do you think that would be acceptable ? Then I'd remove all code that automatically generates tables (which would make the code a lot cleaner and I won't need to find out how to set auto_increment as it's different for each database). Are there any other things I should think about ? Do you think this module could be accepted in FS ? :-) Thanks for the input ! Kind regards, Leon
I haven't looked too closely at this, but had a couple of comments having done a bunch of the work on mod_lcr. 1) Using %q is fragile for custom sql. If the user puts too many in there mprintf is gonna have fits. You might want to look at using a (temp) event, setting vars on it, and then using the var expansion support instead. So, instead of %q, you would use ${varname}. This also makes things more flexible as you go forward in your development. You can see how it is in done in mod_lcr. 2) On the sql, I hope the final won't allow NULL in all fields. Some of those look like auto-increment primary keys which can't be null. Others shouldn't be null (would it make sense to have a null name?). I haven't had a chance to look at the patch. Any chance you can put it in the jira as a diff with a .txt extension? Easier to review that way rather than a tgz. On Thu, Jun 18, 2009 at 4:48 AM, Leon de Rooij <leon@scarlet-internet.nl>wrote:
Hi all,
I'd like to generate user directory xml directly in FS to bypass http +php (or other scripting language) entirely. So I started writing a module to do just that. It's still rough - I don't code c very often - but it works.
http://jira.freeswitch.org/browse/XML-3
Currently all queries are statically defined in the module so users cannot deviate from the sql schema. Bkw suggested to have a look at mod_lcr which look really cool, though I'm not really sure yet how to get the same behavior in this module.
The sql schema (without indexes for readability) currently looks like this:
http://pastebin.freeswitch.org/9427
In the module, I'm doing 7 queries:
Q1: Get domain_id and user_id Q2: Get domain_params Q3: Get domain_variables Q4: Get user_attrs Q5: Get user_params Q6: Get user_variables Q7: Get groups
Where Q2-Q6 should return a list of name/value pairs.
To make things more configurable by the user of the module, I could place all queries in the configuration file, like this:
http://pastebin.freeswitch.org/9426
Do you think that would be acceptable ?
Then I'd remove all code that automatically generates tables (which would make the code a lot cleaner and I won't need to find out how to set auto_increment as it's different for each database).
Are there any other things I should think about ?
Do you think this module could be accepted in FS ? :-)
Thanks for the input !
Kind regards,
Leon
_______________________________________________ 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
-- -Rupa
The module is in scripts/contrib/ledr now. I will try to understand mod_lcr better, reading now :) The sql is fixed. On Thu, 2009-06-18 at 11:44 -0500, Rupa Schomaker wrote:
I haven't looked too closely at this, but had a couple of comments having done a bunch of the work on mod_lcr.
1) Using %q is fragile for custom sql. If the user puts too many in there mprintf is gonna have fits. You might want to look at using a (temp) event, setting vars on it, and then using the var expansion support instead. So, instead of %q, you would use ${varname}. This also makes things more flexible as you go forward in your development. You can see how it is in done in mod_lcr.
2) On the sql, I hope the final won't allow NULL in all fields. Some of those look like auto-increment primary keys which can't be null. Others shouldn't be null (would it make sense to have a null name?).
I haven't had a chance to look at the patch. Any chance you can put it in the jira as a diff with a .txt extension? Easier to review that way rather than a tgz.
On Thu, Jun 18, 2009 at 4:48 AM, Leon de Rooij <leon@scarlet-internet.nl> wrote: Hi all,
I'd like to generate user directory xml directly in FS to bypass http +php (or other scripting language) entirely. So I started writing a module to do just that. It's still rough - I don't code c very often - but it works.
http://jira.freeswitch.org/browse/XML-3
Currently all queries are statically defined in the module so users cannot deviate from the sql schema. Bkw suggested to have a look at mod_lcr which look really cool, though I'm not really sure yet how to get the same behavior in this module.
The sql schema (without indexes for readability) currently looks like this:
http://pastebin.freeswitch.org/9427
In the module, I'm doing 7 queries:
Q1: Get domain_id and user_id Q2: Get domain_params Q3: Get domain_variables Q4: Get user_attrs Q5: Get user_params Q6: Get user_variables Q7: Get groups
Where Q2-Q6 should return a list of name/value pairs.
To make things more configurable by the user of the module, I could place all queries in the configuration file, like this:
http://pastebin.freeswitch.org/9426
Do you think that would be acceptable ?
Then I'd remove all code that automatically generates tables (which would make the code a lot cleaner and I won't need to find out how to set auto_increment as it's different for each database).
Are there any other things I should think about ?
Do you think this module could be accepted in FS ? :-)
Thanks for the input !
Kind regards,
Leon
_______________________________________________ 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
-- -Rupa _______________________________________________ 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
Hi all, I did some more work on mod_xml_odbc, there is no more static xml layout in the module itself. The module is still buggy and not fully functional, but the idea is there.. It's perhaps easiest to look at the configuration file to see how it works: http://fisheye.freeswitch.org/browse/FreeSWITCH/scripts/contrib/ledr/mod_xml... Whenever the directory is searched, the module actually makes a copy of the template that is pointed to from given binding. The idea is that all tags in the template are copied *except* special case <xml-odbc-do> which can trigger things like 'query' or 'break-to'. Right now, in mod_xml_odbc.c http://fisheye.freeswitch.org/browse/FreeSWITCH/scripts/contrib/ledr/mod_xml... at line 250, I create a new switch_hash_t *hash. All headers (key/value pairs) from given switch_event_t *params are copied in it, after that hash is passed on through all functions that need these values. In another function xml_odbc_render_tag, at lines 176 and 206, I want to use these key/pairs from *hash to auto_expand them in a *char. Rupa suggested to use expand instead of %q, which I really like, I think I understand how that works now. There does not seem to be an _expand_ function on switch_hash_t, so using switch_event_t (which has switch_event_expand_headers) for that seems nice. My question is, is it bad behaviour to just pass on *params given to xml_odbc_search (line 238) to my other functions and also add (temporary) headers to it ? Or must I copy all params into a new switch_event_t and use that instead ? Reason for adding key/value pairs to hash (or headers to the event) is that I want to store variables returned by sql select queries in it (function xml_odbc_query_callback, line 137 - not tested yet), so they can be used in expansions later :) I got rid of user_attrs table like swk suggested, it doesn't fit in the way the module works now and this is indeed nicer. The template: http://fisheye.freeswitch.org/browse/FreeSWITCH/scripts/contrib/ledr/mod_xml... can easily be changed to be fully compatible with swk's sql schema :) Also, what do you think of the direction it's going ? regards, Leon
Take a look in my contrib directory theres a SQL schema that I am already using w/ mysql and some same data... It might need to be slightly modified for some recent user directory changes, but this works quite well w/ the curl stuff already and my thoughts were to do exactly what you are starting down the road for now... I don't think its really nessecary to add an additional table for user attribs, where keeping the vars and params split out does since the former are pretty much set by the coders where params and vars can be many and not nessecarily the same everywhere K
From: Leon de Rooij <leon@scarlet-internet.nl> Reply-To: "freeswitch-dev@lists.freeswitch.org" <freeswitch-dev@lists.freeswitch.org> Date: Thu, 18 Jun 2009 11:48:48 +0200 To: "freeswitch-dev@lists.freeswitch.org" <freeswitch-dev@lists.freeswitch.org> Subject: [Freeswitch-dev] mod_xml_odbc
Hi all,
I'd like to generate user directory xml directly in FS to bypass http +php (or other scripting language) entirely. So I started writing a module to do just that. It's still rough - I don't code c very often - but it works.
http://jira.freeswitch.org/browse/XML-3
Currently all queries are statically defined in the module so users cannot deviate from the sql schema. Bkw suggested to have a look at mod_lcr which look really cool, though I'm not really sure yet how to get the same behavior in this module.
The sql schema (without indexes for readability) currently looks like this:
http://pastebin.freeswitch.org/9427
In the module, I'm doing 7 queries:
Q1: Get domain_id and user_id Q2: Get domain_params Q3: Get domain_variables Q4: Get user_attrs Q5: Get user_params Q6: Get user_variables Q7: Get groups
Where Q2-Q6 should return a list of name/value pairs.
To make things more configurable by the user of the module, I could place all queries in the configuration file, like this:
http://pastebin.freeswitch.org/9426
Do you think that would be acceptable ?
Then I'd remove all code that automatically generates tables (which would make the code a lot cleaner and I won't need to find out how to set auto_increment as it's different for each database).
Are there any other things I should think about ?
Do you think this module could be accepted in FS ? :-)
Thanks for the input !
Kind regards,
Leon
_______________________________________________ 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
Yes, I defninitely looked through your contrib dir, more than once :) About the dir_user_attrs table, I really like the way each attribute maps to the name column without translating between username and id, etc. Though you have an entire table less containing many rows and also have an enabled flag, which I don't. If the attrs never change, perhaps that's the way to go.. I hope with the ${variable} thing that Rupa suggests that it may be possible to configure it either way ? About auto_increment id's, isn't that possible with stored procedures with postgresql ? On Thu, 2009-06-18 at 12:24 -0500, Ken Rice wrote:
Also, you'll have to be VERY careful about auto increment ID fields... What works in MySQL doesn't work on Postgresql...
On Thu, 2009-06-18 at 12:20 -0500, Ken Rice wrote:
Take a look in my contrib directory theres a SQL schema that I am already using w/ mysql and some same data... It might need to be slightly modified for some recent user directory changes, but this works quite well w/ the curl stuff already and my thoughts were to do exactly what you are starting down the road for now...
I don't think its really nessecary to add an additional table for user attribs, where keeping the vars and params split out does since the former are pretty much set by the coders where params and vars can be many and not nessecarily the same everywhere
K
From: Leon de Rooij <leon@scarlet-internet.nl> Reply-To: "freeswitch-dev@lists.freeswitch.org" <freeswitch-dev@lists.freeswitch.org> Date: Thu, 18 Jun 2009 11:48:48 +0200 To: "freeswitch-dev@lists.freeswitch.org" <freeswitch-dev@lists.freeswitch.org> Subject: [Freeswitch-dev] mod_xml_odbc
Hi all,
I'd like to generate user directory xml directly in FS to bypass http +php (or other scripting language) entirely. So I started writing a module to do just that. It's still rough - I don't code c very often - but it works.
http://jira.freeswitch.org/browse/XML-3
Currently all queries are statically defined in the module so users cannot deviate from the sql schema. Bkw suggested to have a look at mod_lcr which look really cool, though I'm not really sure yet how to get the same behavior in this module.
The sql schema (without indexes for readability) currently looks like this:
http://pastebin.freeswitch.org/9427
In the module, I'm doing 7 queries:
Q1: Get domain_id and user_id Q2: Get domain_params Q3: Get domain_variables Q4: Get user_attrs Q5: Get user_params Q6: Get user_variables Q7: Get groups
Where Q2-Q6 should return a list of name/value pairs.
To make things more configurable by the user of the module, I could place all queries in the configuration file, like this:
http://pastebin.freeswitch.org/9426
Do you think that would be acceptable ?
Then I'd remove all code that automatically generates tables (which would make the code a lot cleaner and I won't need to find out how to set auto_increment as it's different for each database).
Are there any other things I should think about ?
Do you think this module could be accepted in FS ? :-)
Thanks for the input !
Kind regards,
Leon
_______________________________________________ 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
_______________________________________________ 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
On Thu, Jun 18, 2009 at 2:24 PM, Leon de Rooij <leon@scarlet-internet.nl>wrote:
About auto_increment id's, isn't that possible with stored procedures with postgresql ?
Specifying them is different between databases. Getting the new value for later use is different between databases. For query only -- you shouldn't have a problem. For postgres use the SERIAL data type and all the magic with sequences and junk is done behind the scenes for you. -- -Rupa
Also, you'll have to be VERY careful about auto increment ID fields... What works in MySQL doesn't work on Postgresql...
From: Leon de Rooij <leon@scarlet-internet.nl> Reply-To: "freeswitch-dev@lists.freeswitch.org" <freeswitch-dev@lists.freeswitch.org> Date: Thu, 18 Jun 2009 11:48:48 +0200 To: "freeswitch-dev@lists.freeswitch.org" <freeswitch-dev@lists.freeswitch.org> Subject: [Freeswitch-dev] mod_xml_odbc
Hi all,
I'd like to generate user directory xml directly in FS to bypass http +php (or other scripting language) entirely. So I started writing a module to do just that. It's still rough - I don't code c very often - but it works.
http://jira.freeswitch.org/browse/XML-3
Currently all queries are statically defined in the module so users cannot deviate from the sql schema. Bkw suggested to have a look at mod_lcr which look really cool, though I'm not really sure yet how to get the same behavior in this module.
The sql schema (without indexes for readability) currently looks like this:
http://pastebin.freeswitch.org/9427
In the module, I'm doing 7 queries:
Q1: Get domain_id and user_id Q2: Get domain_params Q3: Get domain_variables Q4: Get user_attrs Q5: Get user_params Q6: Get user_variables Q7: Get groups
Where Q2-Q6 should return a list of name/value pairs.
To make things more configurable by the user of the module, I could place all queries in the configuration file, like this:
http://pastebin.freeswitch.org/9426
Do you think that would be acceptable ?
Then I'd remove all code that automatically generates tables (which would make the code a lot cleaner and I won't need to find out how to set auto_increment as it's different for each database).
Are there any other things I should think about ?
Do you think this module could be accepted in FS ? :-)
Thanks for the input !
Kind regards,
Leon
_______________________________________________ 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
participants (3)
-
Ken Rice
-
Leon de Rooij
-
Rupa Schomaker