| 02:51.13 | *** join/#asterisk-dev jdoe (~jdoe@174.136.97.243) |
| 02:56.22 | *** join/#asterisk-dev jdoe (jdoe@665.be) |
| 03:38.42 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 03:38.42 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 03:40.31 | *** join/#asterisk-dev mog (~mog@c-68-62-169-225.hsd1.al.comcast.net) |
| 04:42.44 | *** join/#asterisk-dev kerframil (~kerframil@gentoo/user/kerframil) |
| 05:12.50 | *** join/#asterisk-dev shamelessn00b (~chatzilla@58-65-172-114.nayatel.pk) |
| 05:29.47 | *** join/#asterisk-dev Juggie (~Juggie@unaffiliated/juggie) |
| 07:18.40 | *** join/#asterisk-dev asterisk-learner (~chatzilla@77.42.241.114) |
| 07:20.21 | *** join/#asterisk-dev philipp64|laptop (~chatzilla@71-34-110-194.ptld.qwest.net) |
| 07:27.11 | *** join/#asterisk-dev shamelessn00b (~chatzilla@58-65-172-114.nayatel.pk) |
| 07:59.06 | *** join/#asterisk-dev hehol (~hehol@buero-gw.dortmund.loca.net) |
| 08:07.24 | *** join/#asterisk-dev tzafrir_laptop (~tzafrir@local.xorcom.com) |
| 08:07.24 | *** mode/#asterisk-dev [+o tzafrir_laptop] by ChanServ |
| 08:11.09 | *** join/#asterisk-dev asterisk-learner (~chatzilla@77.42.241.114) |
| 09:21.16 | *** join/#asterisk-dev tamiel (~tamiel@213.30.183.226) |
| 10:05.25 | *** join/#asterisk-dev schmidts (~schmidts@lmlo.sil.at) |
| 10:05.31 | schmidts | hello |
| 10:22.25 | *** join/#asterisk-dev bbryant (~brett@c-76-26-221-79.hsd1.sc.comcast.net) |
| 10:22.25 | *** mode/#asterisk-dev [+o bbryant] by ChanServ |
| 10:28.22 | *** join/#asterisk-dev mpe (~mpe@0xd99d3f8f.customer.cybercity.dk) |
| 11:22.53 | *** join/#asterisk-dev Marquis42 (~bfhbmw0@65-127-126-34.dia.static.qwest.net) |
| 12:18.19 | asterisk-learner | hello |
| 12:18.48 | asterisk-learner | if i am using ast_pbx_outgoing_exten() to execute a Dial |
| 12:26.16 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 12:26.16 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 12:48.08 | schmidts | short question: what i am doing wrong if a ao2_callback doesnt call its compare function even the container is not empty? |
| 12:48.31 | kpfleming | nothing comes to mind |
| 12:48.54 | kpfleming | what flags are you passing to ao2_callback? |
| 12:49.12 | schmidts | OBJ_POINTER | OBJ_MULTIPLE |
| 12:49.34 | schmidts | cause i want the result from the callback to be used with an ao2_iterator |
| 12:51.37 | schmidts | i didnt see any ref debug message of this callback, if i turn it on |
| 12:53.05 | kpfleming | can you post the code in pastebin? |
| 12:53.21 | schmidts | np |
| 12:54.08 | schmidts | i am still testing so ignore the verbose messages ;) |
| 12:54.17 | schmidts | http://pastebin.com/abca1qc9 |
| 12:55.43 | schmidts | i see the verbose before and after the callback, but i never get the output from inside the function or even a result from this callback |
| 12:56.02 | schmidts | and there are dialogs i can see them with sip show objects |
| 12:57.14 | kpfleming | that's not going to work the way you expect |
| 12:57.40 | kpfleming | OBJ_POINTER means two things: it means your callback function will receive a pointer to each object in the container, but it *also* means you are passing in a pointer to an object like the ones in the container |
| 12:57.48 | kpfleming | ao2_callback will then hash that object to find potential matches |
| 12:57.50 | schmidts | AAAAAAHHHH got it |
| 12:57.52 | schmidts | ok |
| 12:58.11 | kpfleming | and if the hashing is done on the peer name, you won't have to do that comparison in your callback function |
| 12:58.45 | kpfleming | so in other places where this done, the code declares a structure on the stack to act as a 'fake' object, fills it in, then passes it to ao2_callback |
| 12:59.48 | schmidts | i didnt know the second meaning of OBJ_POINTER but i understand it now |
| 13:00.00 | kpfleming | great |
| 13:00.02 | schmidts | the problem is dialogs are hashed by their callid |
| 13:00.09 | schmidts | thx kevin |
| 13:00.25 | kpfleming | ok |
| 13:00.32 | kpfleming | well... you can't use OBJ_POINTER then |
| 13:01.03 | kpfleming | if the docs in astobj2.h don't explain that part of OBJ_POINTER, then they should be improved :-) |
| 13:01.12 | schmidts | i will take a look ;) |
| 13:01.37 | schmidts | <PROTECTED> |
| 13:01.37 | schmidts | <PROTECTED> |
| 13:02.01 | schmidts | i think this is good enough (maybe i shoud read this again ;) |
| 13:02.21 | kpfleming | ok |
| 13:02.30 | schmidts | thank you very much |
| 13:02.35 | kpfleming | well, that's not quite good enough |
| 13:02.43 | kpfleming | the 'if not' should be 'if NULL' |
| 13:03.07 | kpfleming | ao2_callback can't know whether a non-NULL pointer points to an object or not, it will assume any non-NULL pointer points to an object, as you've just learned |
| 13:03.28 | kpfleming | so just remove OBJ_POINTER from your flags and it should work the way you want |
| 13:03.53 | schmidts | i hope so |
| 13:04.25 | schmidts | yes it works!!! |
| 13:21.23 | *** join/#asterisk-dev `mc (~mc@69.37.245.215) |
| 13:21.25 | `mc | I want asterisk to "bridge" two connections together in a click-to-call type scenario. My question isn't as much as how it can be done but what how I would add the ability to have a timer for calls and once that timer is up, the party that initiated the click-to-call is prompted to authorize their account to be charged for credit. So my question is, how would i implement such a feature? Are there third party asterisk providers that do this? |
| 13:21.26 | `mc | Thanks! |
| 13:26.47 | kpfleming | `mc: this is more appropriate for #asterisk |
| 13:26.56 | `mc | ok |
| 13:27.16 | `mc | is this a dialplan channel or development for the asterisk system itself in C? |
| 13:27.31 | schmidts | its for the code of asterisk itself ;) |
| 13:27.41 | `mc | ah ok |
| 13:27.43 | `mc | thanks |
| 13:27.56 | `mc | but hey, asking the developers should be the best, no? |
| 13:29.14 | `mc | im looking for asterisk consultants..know of any> |
| 13:29.16 | `mc | ? |
| 13:30.42 | kpfleming | still off topic |
| 13:30.57 | kpfleming | post on the asterisk-biz mailing list if you are looking to hire someone for development |
| 13:31.51 | `mc | ok |
| 13:31.54 | `mc | sheesh |
| 13:31.57 | `mc | 'p |
| 13:32.12 | seanbright | in the words of `mc: |
| 13:32.21 | seanbright | 12:50 < `mc> btw, why are you such an asshole? |
| 13:32.34 | `mc | haha |
| 13:32.36 | `mc | no, he's not |
| 13:32.42 | seanbright | fantastic... |
| 13:32.44 | `mc | but the guy I originally said that to was |
| 13:32.50 | `mc | at least acting like it |
| 13:33.02 | russellb | an asshole on IRC? unheard of |
| 13:33.06 | `mc | lol |
| 13:33.24 | schmidts | russellb try /join #asshole i am sure this channel exists |
| 13:33.29 | schmidts | :D |
| 13:33.43 | russellb | no thanks |
| 13:33.44 | `mc | oh this is very conforting, I call an asterisk consulting firm and their PBX doesn't even work..wonderful |
| 13:34.28 | russellb | that's why DIgium wouldn't let us run svn trunk on the main pbx anymore :-) |
| 13:34.44 | wdoekes2 | lol |
| 13:35.01 | seanbright | funny... that's why i can't run any version of asterisk |
| 13:35.03 | seanbright | bazinga |
| 13:35.13 | file | seanbright, I hate you. |
| 13:35.15 | seanbright | (i run asterisk... a lot) |
| 13:35.17 | file | seanbright, in a loving way <3 |
| 13:35.24 | kpfleming | everyone does, join the support group |
| 13:36.33 | seanbright | happy monday to you, too. |
| 13:38.20 | *** part/#asterisk-dev `mc (~mc@69.37.245.215) |
| 13:51.57 | *** join/#asterisk-dev sruffell (~sruffell@asterisk/the-kernel-guy/sruffell) |
| 13:51.57 | *** mode/#asterisk-dev [+o sruffell] by ChanServ |
| 13:52.05 | *** join/#asterisk-dev bklang (~bklang@tesla.alkaloid.net) |
| 14:10.27 | *** join/#asterisk-dev rrb3942 (~rbullock@208.34.105.161) |
| 14:12.23 | *** join/#asterisk-dev espiceland (~erin@nat/digium/x-hfyxifrxxbyjpsys) |
| 14:15.18 | pabelanger | exit |
| 14:15.40 | kpfleming | pabelanger: no |
| 14:20.12 | *** join/#asterisk-dev pabelanger (~pabelange@2607:f2c0:a000:166:218:f3ff:fe51:c71) |
| 14:20.12 | *** mode/#asterisk-dev [+o pabelanger] by ChanServ |
| 14:30.51 | *** join/#asterisk-dev putnopvut (~putnopvut@asterisk/master-of-queues/mmichelson) |
| 14:30.51 | *** mode/#asterisk-dev [+o putnopvut] by ChanServ |
| 14:34.40 | *** join/#asterisk-dev Jacke (jacke@valhalla.bofh.org) |
| 14:47.27 | pabelanger | Jacke: ping? |
| 14:56.29 | Jacke | pabelanger: hey ;-) |
| 14:57.17 | pabelanger | Jacke: hey :) builder.ss7.pl is your system, right? |
| 14:58.06 | Jacke | yep |
| 14:58.32 | Jacke | something wrong with it? ;-) |
| 14:58.41 | pabelanger | Jacke: cool, it looks like it went offline on Friday. I tried to send an email to you but looks to have bounced. |
| 14:58.49 | pabelanger | Do you mind checking it out? |
| 14:59.17 | Jacke | pabelanger: It's working now. We indeed had some outage during the weekend, but everything is up and running now. |
| 15:00.00 | pabelanger | Jacke: nice! Thanks for the info |
| 15:00.23 | Jacke | pabelanger: i've just logged in and the machine is up and seems to be fine - if anything is out of order just ping me ;-) |
| 15:00.50 | pabelanger | Jacke: no problem, will do. |
| 15:01.40 | *** join/#asterisk-dev WIMPy (~wimpy@e183095026.adsl.alicedsl.de) |
| 15:22.00 | *** join/#asterisk-dev espiceland (~erin@nat/digium/x-ifuetkdncxsckhos) |
| 15:27.22 | *** part/#asterisk-dev asterisk-learner (~chatzilla@77.42.241.114) |
| 15:29.08 | *** join/#asterisk-dev Deeewayne (~dwayne@75-150-14-49-Atlanta.hfc.comcastbusiness.net) |
| 15:29.16 | *** mode/#asterisk-dev [+o Deeewayne] by ChanServ |
| 15:44.37 | *** join/#asterisk-dev jpeeler (~jpeeler@asterisk/developer/jpeeler) |
| 15:44.37 | *** mode/#asterisk-dev [+o jpeeler] by ChanServ |
| 15:45.55 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 15:45.55 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 15:50.30 | *** join/#asterisk-dev anthm (~anthm@freeswitch/developer/anthm) |
| 15:51.27 | *** join/#asterisk-dev bklang (~bklang@tesla.alkaloid.net) |
| 15:59.58 | *** join/#asterisk-dev kpfleming (~kpfleming@asterisk/digium-director-of-software-tech/kpfleming) |
| 15:59.58 | *** mode/#asterisk-dev [+o kpfleming] by ChanServ |
| 16:00.20 | *** join/#asterisk-dev The_Boy_Wonder (~vossel@asterisk/batman-developer/dvossel) |
| 16:00.20 | *** mode/#asterisk-dev [+o The_Boy_Wonder] by ChanServ |
| 16:00.52 | *** join/#asterisk-dev Qwell (~north@pdpc/sponsor/digium/Qwell) |
| 16:00.52 | *** mode/#asterisk-dev [+o Qwell] by ChanServ |
| 16:05.09 | *** join/#asterisk-dev BMJ (~bjohns@c-24-126-158-110.hsd1.ga.comcast.net) |
| 16:05.10 | *** mode/#asterisk-dev [+o BMJ] by ChanServ |
| 16:05.22 | *** join/#asterisk-dev leifmadsen (~Leif@asterisk/documenteur-extraordinaire/blitzrage) |
| 16:05.22 | *** mode/#asterisk-dev [+o leifmadsen] by ChanServ |
| 16:08.24 | *** join/#asterisk-dev datachomper (~Adium@nat/digium/x-cweleqhjxadlfztp) |
| 16:09.41 | *** join/#asterisk-dev Corydon76-lap (~Adium@nat/digium/x-eykeuqwnpqhwaeei) |
| 16:09.41 | *** mode/#asterisk-dev [+o Corydon76-lap] by ChanServ |
| 16:12.20 | *** join/#asterisk-dev mnicholson (~mnicholso@nat/digium/x-dthfmcwyhlkrgeqz) |
| 16:13.46 | *** join/#asterisk-dev frawd (~francois@108.Red-83-35-162.dynamicIP.rima-tde.net) |
| 16:14.27 | *** join/#asterisk-dev elguero (~miguel323@12.187.84.162) |
| 16:29.31 | *** join/#asterisk-dev datachomper (~Adium@nat/digium/x-ywelzlwagkoxhubv) |
| 16:43.01 | *** join/#asterisk-dev marv (~timr@24.214.206.254) |
| 17:02.43 | *** join/#asterisk-dev frawd (~francois@108.Red-83-35-162.dynamicIP.rima-tde.net) |
| 17:37.47 | Qwell | sruffell: ping? |
| 17:42.01 | *** join/#asterisk-dev bklang (~bklang@c-66-56-8-144.hsd1.ga.comcast.net) |
| 17:45.03 | sruffell | pong |
| 17:45.40 | sruffell | or rather Qwell: pong (I see it's been awhile since you pinged) |
| 17:45.59 | Qwell | sruffell: thoughts on adding an install-tests target for dahdi-tools? http://pastebin.ca/2005927 |
| 17:46.36 | *** join/#asterisk-dev crowbar7 (~JKLOBUCAR@12.2.84.2) |
| 17:47.42 | sruffell | makes sense to me. |
| 17:48.04 | Qwell | should I commit? been a long time since I've committed to dahdi. |
| 17:50.04 | sruffell | I think so....I just wouldn't make that installed by default (but I see you didn't) since some of the test bins don't indicate that they are from DAHDI. So...Acked-by: Shaun Ruffell <sruffell@digium.com> |
| 18:22.33 | *** join/#asterisk-dev jsmith (~jsmith@fedora/jsmith) |
| 18:22.35 | *** mode/#asterisk-dev [+o jsmith] by ChanServ |
| 18:41.44 | *** join/#asterisk-dev TheDavidFactor (~chatzilla@nc-71-52-234-23.dhcp.embarqhsd.net) |
| 18:56.30 | *** join/#asterisk-dev bneff (~bneff@12.104.144.2) |
| 19:11.09 | *** join/#asterisk-dev TheDavidFactor (~chatzilla@nc-71-52-234-23.dhcp.embarqhsd.net) |
| 19:39.00 | *** join/#asterisk-dev MuffinMan (~muffinman@asterisk/issue-tracker-bot/muffinman) |
| 21:21.58 | russellb | anyone want to do a really quick code review on a tweak to transmit_publish() in chan_sip.c? It looks like an error handling block wasn't complete ... http://pastebin.com/UZwCTWrx |
| 21:22.11 | russellb | putnopvut: twas your code if it's not a bad time... ^^^ |
| 21:23.46 | putnopvut | looking. |
| 21:24.29 | russellb | I didn't hit a problem with it, just caught my eye |
| 21:25.30 | putnopvut | Yeah, that looks fine by moi |
| 21:25.41 | russellb | thanks! |
| 21:42.44 | citywok | russellb: can you tell without me having to recompile the module and test the debug output if line 6473 in app_queue would set member_reload to true if queue reload all is executed |
| 21:43.01 | russellb | version? |
| 21:43.05 | citywok | trunk |
| 21:44.43 | russellb | ye |
| 21:44.43 | russellb | yes |
| 21:44.54 | citywok | so it should be set? hrmmm. okie. |
| 21:45.01 | russellb | should be |
| 21:45.03 | russellb | doesn't mean it is |
| 21:45.05 | citywok | queue reload all works fairly regularly. queue reload member doesnt |
| 21:45.15 | citywok | i'll add some debug output and see if i can find it |
| 21:45.40 | russellb | that's invalid |
| 21:45.43 | russellb | "queue reload members" |
| 21:45.46 | russellb | note the trailing 's'. |
| 21:45.59 | russellb | "queue reload member" will do a bunch of nothing |
| 21:46.04 | russellb | silent failure it looks like, heh |
| 21:46.20 | citywok | i was doing members. i tab complete to make sure. |
| 21:46.29 | citywok | i just didn't type ita ll the way out in here, ignore that :) |
| 21:46.32 | russellb | k |
| 21:46.49 | citywok | i tab compelted to see what the available options were before doing anything else. i've never used anything other than reload all myself. |
| 21:47.00 | citywok | queue reload all that is |
| 21:47.35 | citywok | yona's comments are exactly the same behavior i was getting, which was very confusing |
| 21:47.53 | citywok | if you do members, then all, it won't work on all either. |
| 21:48.29 | citywok | so maybe the queue_reload_parameters & queue_reload_member flags aren't being set/unset properly? |
| 21:49.26 | russellb | try changing ... struct ast_flags config_flags = { reload ? CONFIG_FLAG_FILEUNCHANGED : 0 }; |
| 21:49.32 | russellb | change that to = { 0 } |
| 21:49.38 | russellb | I think that is screwing with you |
| 21:49.47 | russellb | and I think that's probably the right thing to do, anyway |
| 21:50.05 | russellb | because it may be remembering that it hasn't changed since the last config load, but your last load could have been for "members" only |
| 21:50.09 | russellb | and now you want to reload "all" |
| 21:50.18 | russellb | it needs to load the config file every time because of that |
| 21:50.31 | citywok | oh, yea. if we are reloading now we should clear the flags... |
| 21:50.40 | Corydon76-lap | russellb: probably should change the "who_asked" value for each to distinct values |
| 21:50.48 | citywok | that makes sense. |
| 21:50.49 | russellb | Corydon76-home: yeah, that could work too |
| 21:50.53 | russellb | i forgot about that |
| 21:51.39 | Corydon76-lap | I believe the default is a macro right now |
| 21:51.49 | Corydon76-lap | using __FILE__ |
| 21:51.50 | citywok | compiling it now, we'll see shortly. |
| 21:51.58 | russellb | AST_MODULE |
| 21:52.14 | Corydon76-lap | Ah, that's it |
| 21:53.37 | citywok | russellb: i'm not sure thati's going to do it. reload will always be 1 when called by reload_handler back at 7252 |
| 21:54.30 | russellb | yes i know |
| 21:54.32 | Corydon76-lap | citywok: yes, but if you set the config flags to 0, it will load the config file regardless of whether nothing has changed or not. |
| 21:54.33 | russellb | that's why i'm saying to remove that code |
| 21:54.39 | russellb | what Corydon76-lap said. |
| 21:55.25 | citywok | gotcha |
| 21:55.57 | citywok | testing, hold preez |
| 21:56.00 | Corydon76-lap | It's generally a smart flag to avoid doing unnecessary work⦠this is just a fail instance |
| 21:57.03 | citywok | okay, that did fix that. |
| 21:57.16 | citywok | queue reload members doesn't block all from working next pass |
| 21:57.26 | citywok | but members doesn't pick up the change, so something is still broken there. |
| 21:58.33 | citywok | ah, it doesn't execute the pruning step if you do queue reload members. didn't get my debug output as i expected. |
| 22:05.00 | citywok | Ah, there's a return @ 6506 that we're hitting with reload members but not all. |
| 22:05.53 | citywok | russellb: can i modify line 6499 to add && (!member_reload && queue_reload) to fix that case? |
| 22:06.29 | citywok | whoops, reverse the ! |
| 22:08.49 | citywok | got it. 6499 needs to be if (q->found && queue_reload) { |
| 22:10.17 | citywok | hah, actually i think that entire code block needs to go away. we basically never want to bail out at this point. |
| 22:13.00 | *** join/#asterisk-dev frawd (~francois@53.Red-88-13-130.dynamicIP.rima-tde.net) |
| 22:17.34 | Corydon76-lap | citywok: put it up on reviewboard |
| 22:18.11 | citywok | looking at all the code below it, there are multiple cases where that block is preventing code from executing. so i'm pruning it out and re-testing. reviewboard or bugtracker? |
| 22:21.18 | *** join/#asterisk-dev elguero (~miguel323@207.154.34.162) |
| 22:23.31 | *** join/#asterisk-dev erinspice (~erin@207.98.195.107) |
| 22:23.34 | citywok | Hah, somebody fixed it in the last week. I was a week behind trunk and it wasn't patched. Having done an update, somebody arleady fixed it. |
| 22:26.32 | citywok | same for the { 0 } line |
| 22:28.18 | russellb | huh. |
| 22:28.28 | citywok | bbryant on 11/19 fixed it |
| 22:28.40 | russellb | and it didn't get merged up to trunk? |
| 22:30.02 | Corydon76-lap | Score for Brett |
| 22:30.26 | Corydon76-lap | (Yes, people do work on holidays) |
| 22:30.48 | russellb | citywok: you are confused. His patch on that day didn't touch any code related to this |
| 22:31.22 | citywok | yea, eclipse and i disagree. i told it to update and opened it, but it didn't show me the udpated version. |
| 22:32.08 | citywok | i just told it to revert in eclipse and now it shows it as the current version with the extra code |
| 22:32.44 | citywok | so really... i just suck at eclipse lol |
| 22:38.17 | *** join/#asterisk-dev rrb3942 (~rbullock@cpe-67-242-215-62.rochester.res.rr.com) |
| 22:40.12 | russellb | s/at eclipse lol// |
| 22:40.16 | russellb | :-p |
| 22:40.30 | citywok | mean :P |
| 22:40.49 | russellb | just kiddinggggg |
| 22:41.15 | russellb | I appreciate you working on the problem |
| 22:41.20 | russellb | you'll be addicted to asterisk development soon |
| 22:41.28 | citywok | so the logic is there to prevent code from being unnecessarily executed, but I think it's redundant, pretty much everything below independently verifies whether or not it should be reloading. |
| 22:41.29 | russellb | and the plan will have worked perfectly. |
| 22:41.52 | citywok | hahaha, there was a plan?! |
| 22:41.56 | russellb | yup |
| 22:42.18 | citywok | so I think the solution is to simply remove the 8 line block at 6503 |
| 22:42.26 | russellb | dev projects and commit access == crack |
| 22:42.52 | citywok | heh, yea learning something new is always fun :) |
| 22:43.02 | citywok | rather than just post a bug report... go see if you can figure out WHY it breaks |
| 22:43.17 | citywok | that said i looked at the calendaring module... still over my head |
| 22:44.06 | citywok | the { 0 } code is unnecessary, reload members then reload all works properly having removed that block. |
| 22:44.25 | russellb | I don't believe you |
| 22:44.40 | citywok | heh, i was just testing whether or not that was needed. i'll include it as cleanup anyways. |
| 22:45.56 | citywok | are you sure do we want to remove the logic about testing fileunchanged? |
| 22:46.51 | russellb | no |
| 22:46.59 | russellb | but it seemed like the right idea |
| 22:47.05 | russellb | you tell me |
| 22:48.17 | citywok | we can remove half of it, reload is always 1 by design in previous code. but we should skip it assuming the fileunchanged flag is working properly, and it seems to be. |
| 22:48.59 | citywok | but for simplicity, and considering reload COULD come in as a 0 at some point (though as it is now it never would get to be a 0), i'd leave that part too. |
| 22:52.59 | *** join/#asterisk-dev datachomper (~Adium@207.98.189.248) |
| 22:58.58 | Corydon76-lap | citywok: the right thing to do is to change the "who_asked" argument |
| 22:59.27 | Corydon76-lap | citywok: so that the module has two (or more) different values |
| 22:59.40 | Corydon76-lap | one for each type of reload |
| 23:00.06 | citywok | it already has a value for reload all, and reload members |
| 23:00.17 | citywok | and the logic follows it below this errant code |
| 23:00.35 | Corydon76-lap | citywok: are you sure? |
| 23:00.58 | citywok | that's what it looks like to me, but sure? no. |
| 23:01.45 | citywok | 6477 & 6478 are testing for members right? |
| 23:02.12 | Corydon76-lap | citywok: it is not, because the code is calling ast_config_load and not ast_config_load2 |
| 23:04.35 | citywok | are you talking about 6605? what's the diff between load & load2? |
| 23:04.58 | Corydon76-lap | load2 lets you set a different "asker" |
| 23:05.32 | Corydon76-lap | ast_config_load implicitly assumes it's the name of the module, and that there's only one kind of load going on |
| 23:06.22 | Corydon76-lap | So I would suggest when reloading members only, you make that string be "app_queue_members" |
| 23:06.26 | citywok | oh, so for example you could change it to be "app_queue reload members" or "app_queue reload all" |
| 23:07.03 | Corydon76-lap | "app_queue" for the general case and "app_queue_members" for the members-only case |
| 23:07.09 | citywok | gotcha, makes sense to me |
| 23:07.46 | Corydon76-lap | It's not completely perfect; a reload on "all" should imply a members reload, but that's a limitation of the API |
| 23:07.59 | citywok | got somewhere with an example of it? i've worked in meetme, confbridge, and queue and don't see any examples. |
| 23:09.40 | Corydon76-lap | This may be the first application that actually will ever have separate arguments |
| 23:11.01 | Corydon76-lap | There are others that call the API directly, but none appear to use different arguments, depending on what is invoking the reload |
| 23:11.27 | Corydon76-lap | but see include/asterisk/config.h for the prototype |
| 23:15.01 | Corydon76-lap | We might could change the API once again to include a bitfield along with the "who_asked" field, so that you could have subsets of "all", defined by the application, of course. |
| 23:15.49 | Corydon76-lap | That would solve it perfectly, although I don't know if it's worth the pain of changing the API. |
| 23:16.38 | Corydon76-lap | This fix would work fine for 1.8, though, and maybe we just make the API change in 1.10 forward |
| 23:17.42 | Corydon76-lap | Is the fix needed for anything earlier than 1.8? |
| 23:21.01 | citywok | i'll have to take a look at it to see |
| 23:21.36 | citywok | Corydon76-lap: i haven't tested it. it was pointed out in #asterisk as an issue in 1.8 |