**** BEGIN LOGGING AT Sat Jun 05 02:59:57 2010 Jun 05 11:55:51 nbd * r21679 /trunk/target/linux/ar71xx/nand/target.mk: ar71xx: clarify the nand subtarget a bit Jun 05 18:26:43 juhosg * r21680 /trunk/target/linux/adm5120/ (28 files in 12 dirs): adm5120: convert to use the new mips multimachine stuff Jun 05 18:26:46 juhosg * r21681 /trunk/target/linux/generic-2.6/ (3 files in 3 dirs): generic: update mips multimachine patch Jun 06 00:44:57 ping xMff Jun 06 00:45:12 ping other-devs Jun 06 00:45:51 I'd like an opinion on how to hand a package that I will be createing for freeswitch Jun 06 00:45:58 *handle Jun 06 00:46:49 I'm getting started with a GUI for freeswitch and am starting with a version that is specific to the provider the company I work for works with Jun 06 00:47:21 I'm wondering about splitting the freeswitch configs into freeswitch-config-default and freeswitch-config-accessline for now Jun 06 00:48:13 Ideally we could have a freeswitch-config-common which does the conversion from UCI to FS's xml Jun 06 00:48:37 and other common functions Jun 06 00:49:16 and provider-specific configs too Jun 06 00:49:55 I don't want to make accessline simply a common config right now because it will be a very limited subset of available functionality Jun 06 00:50:41 but I don't really like the per-provider configs either Jun 06 01:03:02 how complex is the xml? Jun 06 01:03:24 xMff: not very Jun 06 01:03:30 how deeply nested? Jun 06 01:04:22 xMff: it's mostly split into separate files in a directory hiearchy....dir nesting is 2-4 levels and the files have 2-4 levels of XML nesting Jun 06 01:05:03 ok Jun 06 01:05:05 xMff: however the XML nesting is the same root Jun 06 01:05:19 and whats the actual problem? Jun 06 01:05:20 xMff: not 2-4 dir + 2-4 xml Jun 06 01:05:37 the uci xml conversation should be generic Jun 06 01:06:01 xMff: yes, but for starters I will be working on only those things needed by the specific provider Jun 06 01:06:14 xMff: There's a *lot* of configuration stuff Jun 06 01:06:19 then do a template mechanism like for samba Jun 06 01:06:49 xMff: I was thinking of recipes like OpenVPN Jun 06 01:07:21 xMff: I want the user to be able to specify a particular provider and only have to fill in info for that provider Jun 06 01:07:57 xMff: rather than a generic form...the generic form would be for Admin, the per-provider for Essentials Jun 06 01:08:33 xMff: basically the idea is to make known providers dead simple to configure Jun 06 01:11:32 xMff: the other option is to have a separate LuCI page for each provider, but use the same backend for the UCI conversion Jun 06 01:11:44 well Jun 06 01:12:10 keep it simple Jun 06 01:12:29 supporting many options just upsets users because stuff is "too complex" Jun 06 01:12:58 xMff: exactly, that's why I'm thinking a per-provider page...each provider page only has the info to fill out for a particular provider Jun 06 01:13:15 yeah, and some standard stuff like dialpans Jun 06 01:13:20 xMff: right Jun 06 01:13:26 rest can be done on the cli Jun 06 01:13:43 or maybe you build some kind of text editor, a textarea with a tree of xml files Jun 06 01:14:22 xMff: hmmm....you mean for the 'Admin' version, rather than trying to UCI-ize the whole thing Jun 06 01:14:50 yeah Jun 06 01:16:08 xMff: I'll have to think about how to accomplish that, but yeah, it'd definitely be better to not have to create UCI conversion for things I'm never going to use (or test) Jun 06 01:17:35 xMff: or I could do like same and the Admin has all UCI options,but if you want something not in UCI you have use cli Jun 06 01:18:45 xMff: I know how to do it...I can have one config tree for UCI config, and use the default config tree (only included if selected in admin, using UCI) as an include for those who need non-standard stuff Jun 06 01:20:04 xMff: at least until I get time to build an system for editing the tree of files in textareas Jun 06 01:24:43 xMff: okay, to sum up: have fs-config-common that has the UCI to XML conversion for what we do 'know' about, fs-config-original for the default config tree (which can be enabled via UCI), luci-app-freeswitch-admin, luci-app-freeswitch-mini-accessline? Jun 06 01:25:10 uhm, whatever fits Jun 06 01:28:23 xMff: also, whats the best way to get the scans (for devices/phones) to not have a CGI timeout? Jun 06 01:29:02 post some body data early and flush stdout Jun 06 01:29:11 xMff: ok Jun 06 01:29:30 as soon as header parsing is finished, the timeout is cleared Jun 06 01:29:37 xMff: right Jun 06 01:30:05 xMff: I'm hoping I can get them ready for inclusion in non-trunk Jun 06 01:30:07 even better would be a background process Jun 06 01:30:33 xMff: I thought of that....basically a daemon, and the LuCi just reads the output Jun 06 01:30:52 yes Jun 06 01:31:32 xMff: yeah, I think I'll do that...that's certainly the best in terms of response time Jun 06 01:32:40 xMff: is there a standard way to include something in the systemwide crontab? Jun 06 01:32:51 no Jun 06 01:33:02 I fiddle my stuff in with grep -q || echo >> ... usually Jun 06 01:33:19 xMff: yeah, that's what I'll do Jun 06 01:33:37 or we introduce /etc/cron.d/ Jun 06 01:33:46 xMff: that would be better IMO Jun 06 01:35:10 xMff: hmmm....but wouldn't that require support by the cron daemon? Jun 06 01:35:32 xMff: how about just standard entries like cron.hourly, cron.daily, etc like on Debian? Jun 06 01:35:38 catting /etc/crontabs root together in init is probably enough Jun 06 01:35:50 that too, yes Jun 06 01:37:44 xMff: also I think boot should be split into separte init entries...I've found, for instance, that syslog logging to remote host needs to be restarted if the host isn't available when syslog is first started (syslog just gives up on it) Jun 06 01:38:22 all services are affected by this Jun 06 01:38:44 all services that bind to specific addresses or that rely on specific addresses may fail Jun 06 01:39:40 xMff: right, but I think rsyslog, for example, retries periodically....it the syslog that's limited Jun 06 01:40:09 it needs to be patched then Jun 06 01:40:26 xMff: anyway, it means I need to sometimes restart syslog without the whole boot Jun 06 01:47:09 xMff: which seem to me useful otherwise too....which is why I'm thinking boot should be split up into boot_XXX_subpart Jun 06 01:47:29 lets defer that Jun 06 01:47:31 xMff: for /etc/boot.d Jun 06 01:47:35 xMff: ok **** ENDING LOGGING AT Sun Jun 06 02:59:56 2010