| 00:08.58 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-qvgndmsgvpkniiwb) |
| 03:36.31 | *** join/#asterisk-dev infobot (ibot@208.53.50.136) |
| 03:36.31 | *** topic/#asterisk-dev is Asterisk Development Discussion -=- http://www.asterisk.org/developers -=- Tier 2 and 3.14159265 support is in #asterisk -=- Check out our blog! blogs.asterisk.org -=- Follow on Twitter at @AsteriskDev |
| 06:46.56 | *** join/#asterisk-dev stevedavies (~stevedavi@197.155.252.3) |
| 06:56.34 | *** join/#asterisk-dev tsearle (~tsearle@37.19.10.33) |
| 06:56.34 | *** mode/#asterisk-dev [+o tsearle] by ChanServ |
| 07:44.05 | *** join/#asterisk-dev pchero_work (~pchero@87.213.240.121) |
| 07:44.36 | *** join/#asterisk-dev pchero_work (~pchero@87.213.240.121) |
| 07:48.06 | *** join/#asterisk-dev CELYA_ (~Thunderbi@cust-west-pareq2-46-193-13-114.wb.wifirst.net) |
| 08:38.57 | *** join/#asterisk-dev hehol (~hehol@gatekeeper.loca.net) |
| 08:41.46 | *** join/#asterisk-dev CELYA_ (~Thunderbi@cust-west-pareq2-46-193-13-114.wb.wifirst.net) |
| 12:02.41 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.61) |
| 12:16.50 | *** join/#asterisk-dev pc-m (~pcm@modemcable094.94-70-69.static.videotron.ca) |
| 13:15.20 | gtjoseph | file: can you take a look at subscription_invoke post-filter-commit (given your power situation)? |
| 13:15.29 | file | yes |
| 13:15.53 | gtjoseph | 'splain please... using the message type id of the change type... |
| 13:16.17 | gtjoseph | and using !final in the callback test instead of final. |
| 13:17.11 | file | the actual filtering of the underlying message type id is done before subscription_invoke is executed |
| 13:17.21 | file | but as you see there's special logic for "final" messages |
| 13:17.45 | gtjoseph | yeah in dispatch i know |
| 13:17.59 | gtjoseph | but we should always callback on final yes? |
| 13:18.11 | file | we don't have to |
| 13:18.14 | file | some subscribers don't care |
| 13:18.28 | file | those that care add stasis_subscription_change_type as a message type |
| 13:19.15 | gtjoseph | ok so you're relying on them now adding that type to get final. |
| 13:19.22 | file | it's usually subscribers that have data attached that need to unref |
| 13:19.22 | file | yes |
| 13:21.11 | gtjoseph | ok so that's kinda a break in the contract for third-party modules no? |
| 13:21.33 | gtjoseph | well , maybe not |
| 13:21.40 | file | it's only done when selective filtering is enabled |
| 13:23.05 | file | I also documented that in stasis_subscription_accept_message_type doxygen, but if there's another place that would be good for it then that'd be good toooooooo |
| 13:24.04 | gtjoseph | yeah i saw the doxygen but it didn't jive exactly with what i was seeing at first. |
| 13:24.25 | gtjoseph | i'll add a comment in subscription_invoke |
| 13:24.28 | file | could probably use a code comment then |
| 13:24.29 | file | yeah |
| 13:25.42 | gtjoseph | i also forgot that the vector was indexed by the message type id. |
| 13:25.58 | file | indeed |
| 13:26.05 | file | I wanted it to be quick. |
| 13:26.12 | gtjoseph | yep makes perfect sense |
| 13:26.28 | gtjoseph | just had to think it though again |
| 13:32.33 | gtjoseph | and just to be clear...i'm ANDing the filter by type and filter by formatter so the logic will be ... (!type_filter || (type1 || type2 ...)) && (!format_filter || (format1 || format2 ...)) |
| 13:33.24 | file | that hurts my head |
| 13:33.38 | gtjoseph | yeah it did as i was typing it |
| 13:34.48 | file | will the end result be that a subscriber can specify message types they want to ensure they get regardless, as well as messages that have a filter (even if the message type isn't explicitly added)? |
| 13:35.23 | gtjoseph | that hurt my head as well. |
| 13:35.29 | gtjoseph | let me restate |
| 13:35.52 | gtjoseph | to get the message, both filters must pass. |
| 13:36.12 | file | so the message type has to be added, and it has to have a to_ami? |
| 13:37.02 | gtjoseph | let's take the case of ami... |
| 13:38.12 | file | oh, I think I understand your original ANDing |
| 13:38.37 | gtjoseph | you call stasis_subscription_accept_formatter_type(STASIS_SUBSCRIPTION_FORMATTER_AMI) |
| 13:39.16 | gtjoseph | and you get all messages with a to_ami formatter regardless of type. |
| 13:39.45 | file | yup |
| 13:39.47 | gtjoseph | if you also specify types using your calls, then you only get messages that match both the type filter and the formatter filter. |
| 13:40.16 | file | ah, I think that should be an OR |
| 13:40.29 | gtjoseph | orly? |
| 13:40.55 | gtjoseph | so give me all that have to_ami OR match the type filter? |
| 13:41.02 | file | yeah |
| 13:41.29 | file | in the case of the stasis_subscription_change_type it has no formatter, but you still may want to receive it along with messages that have a to_json or to_ami |
| 13:41.36 | gtjoseph | but that would mean that you'd get messages you potentially couldn't format for your purposes. |
| 13:42.04 | gtjoseph | maybe the change type should be a "special" |
| 13:42.43 | file | I'm hesitant to make it special in that way, because if there are other cases where the subscriber doesn't just format - but uses the message for some other reason, then it too would have to be special |
| 13:42.46 | file | that's my kinda fear |
| 13:42.53 | gtjoseph | maybe add a STASIS_SUBSCRIPTION_FILTER_FORCED_CHANGES or something |
| 13:43.05 | gtjoseph | yeah OK |
| 13:44.00 | file | I don't think we currently do that, but I'd hesitate on locking ourselves into that model just in case |
| 13:44.30 | gtjoseph | no prob |
| 13:45.18 | file | I'm interested in what the result of this will be... as AMI currently gets all the channel snapshot stuff and now won't |
| 13:45.48 | gtjoseph | i'm almost done so we'll know shortly. :) |
| 14:03.09 | *** join/#asterisk-dev sh_smith (~sh_smith@cpe-76-174-26-91.socal.res.rr.com) |
| 14:32.42 | gtjoseph | this logic is UGLY |
| 14:33.37 | file | I think I went through 5 iterations on mine to make it look a bit saner |
| 14:33.53 | gtjoseph | the case for accepting or dropping based on formatter is dependent on whether the subscriber specified a message type filter ornot |
| 14:33.57 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-mrnqamwbviyhmhvh) |
| 14:33.57 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:36.13 | gtjoseph | to write drop logic or accept logic... that is the question. |
| 15:16.01 | *** join/#asterisk-dev rmudgett (rmudgett@nat/digium/x-cntwsptgyurcmknm) |
| 15:16.01 | *** mode/#asterisk-dev [+o rmudgett] by ChanServ |
| 15:37.23 | *** join/#asterisk-dev kharwell (kharwell@nat/digium/x-cxjxbspbsldjvplr) |
| 15:37.23 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 16:04.22 | *** join/#asterisk-dev dcollins0 (~dandann00@2601:840:8401:d7ee:cd87:f9f3:b237:db82) |
| 16:47.15 | *** join/#asterisk-dev cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 16:47.15 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 17:26.14 | *** join/#asterisk-dev jkroon (~jkroon@165.16.204.41) |
| 18:11.18 | *** join/#asterisk-dev coreyfarrell (~coreyfarr@24-181-237-90.dhcp.oxfr.ma.charter.com) |
| 18:11.18 | *** mode/#asterisk-dev [+o coreyfarrell] by ChanServ |
| 21:12.22 | seanbright | ewww |
| 21:12.39 | seanbright | 10718 makes me sad |
| 21:12.53 | seanbright | will live |
| 21:13.14 | gtjoseph | it's only temporary so we can get an RC out the door, then it'll go back in. |
| 21:14.33 | seanbright | i'll allow it |
| 21:15.19 | gtjoseph | whew |
| 21:15.31 | gtjoseph | dodged a bullet |
| 21:15.36 | rmudgett | :P |
| 21:15.49 | seanbright | there goes your christmas gift |
| 21:16.34 | gtjoseph | that's ok. i have a birthday coming up. |
| 21:16.40 | seanbright | oh yeah? when? |
| 21:16.42 | coreyfarrell | no dependent patches for the app_voicemail stasis stuff? I ask since lots of stuff has happened to stasis |
| 21:17.18 | gtjoseph | seanbright: dec 19th |
| 21:17.34 | seanbright | nice. i'm jan 8th. |
| 21:17.42 | gtjoseph | coreyfarrell: nope. there were a few conflicts in app_voicemail to resolve but otherwise the revert was fairly clean |
| 21:17.42 | seanbright | the big 4-0 |
| 21:18.13 | gtjoseph | that's all? I thought you were pushing 90 as grumpy as you've been. |
| 21:18.55 | seanbright | i'm only grumpy when you don't bend over backwards and do what i command |
| 21:19.04 | coreyfarrell | gtjoseph: cool.. though I was more interested in the stuff that's been done to main/stasis* (stasis_cache?) |
| 21:19.23 | seanbright | would like to recall the message "i'm only grumpy wh..." |
| 21:19.31 | gtjoseph | seanbright: uh huh. |
| 21:20.17 | gtjoseph | coreyfarrell: yeah it's just the voicemail part that was an issue and it really had nothing to do with stasis., It was just cleaner to revert that commit than try to fix the logic. |
| 21:20.43 | coreyfarrell | git rm apps/app_voicemail.c |
| 21:21.36 | gtjoseph | yeah, that would have been the cleanest :) |
| 22:25.02 | *** join/#asterisk-dev pchero (~pchero@dhcp-077-249-058-090.chello.nl) |
| 23:09.07 | *** part/#asterisk-dev kharwell (kharwell@nat/digium/x-cxjxbspbsldjvplr) |