| 05:53.18 | *** join/#asterisk-dev infobot (ibot@c-174-52-60-165.hsd1.ut.comcast.net) |
| 05:53.18 | *** topic/#asterisk-dev is Take the March 2019 Asterisk User Survey! https://goo.gl/forms/xL1VUHRsf95saly13 -- 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:55.50 | *** join/#asterisk-dev spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 07:16.19 | *** join/#asterisk-dev CELYA_ (~Thunderbi@2a01cb0583d31d00f4d7ddd1bc0987bc.ipv6.abo.wanadoo.fr) |
| 07:37.57 | *** join/#asterisk-dev pchero_work (~pchero@2a02:a210:2241:6480:11f6:aca2:9efe:7efc) |
| 10:04.52 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@lfbn-nan-1-2297-47.w92-139.abo.wanadoo.fr) |
| 10:57.14 | *** join/#asterisk-dev spatel (~spatel@pool-96-237-230-175.bstnma.fios.verizon.net) |
| 11:11.31 | *** join/#asterisk-dev pchero_work (~pchero@51.247.195.35.bc.googleusercontent.com) |
| 11:36.02 | *** join/#asterisk-dev AsteriskRoss (~AsteriskR@r01.nt-r1.nor.gb.voicehost.co.uk) |
| 12:12.15 | *** join/#asterisk-dev sduthil (~sduthil@107-179-252-17.cpe.teksavvy.com) |
| 14:00.04 | *** join/#asterisk-dev kharwell (uid358942@gateway/web/irccloud.com/x-jsskhxxddvkvlivr) |
| 14:00.04 | *** mode/#asterisk-dev [+o kharwell] by ChanServ |
| 14:32.03 | gtjoseph | coreyfarrell: do you have some time to weigh in on a bunch of reviews that add res_pjsip_session to load dependencies? |
| 14:32.10 | gtjoseph | Specifically https://gerrit.asterisk.org/c/asterisk/+/14258 et al. |
| 14:32.34 | gtjoseph | We moved the session_supplement stuff to res_pjsip to avoid a dependency loop didn't we? |
| 14:32.57 | gtjoseph | so adding res_pjsip_session back to the load dependencies would be an issue, no? |
| 14:33.38 | coreyfarrell | difficult to remember, I think we moved some stuff from res_pjsip_session to res_pjsip to avoid a dependency loop between those two modules |
| 14:33.50 | gtjoseph | maybe that was it. |
| 14:35.17 | *** join/#asterisk-dev bford (uid283514@gateway/web/irccloud.com/x-opmohrldehzualft) |
| 14:35.17 | *** mode/#asterisk-dev [+o bford] by ChanServ |
| 14:37.17 | coreyfarrell | TBH I'm not clear the benefit of res_pjsip_session.so being separate from res_pjsip.so beyond "that's the way it is"? |
| 14:37.59 | coreyfarrell | is it possible to do anything functional with res_pjsip.so but not res_pjsip_session.so? |
| 14:38.16 | file | registrar, pubsub |
| 14:38.52 | file | in the beginning we opted to modularize as we could |
| 14:45.00 | *** join/#asterisk-dev cresl1n (uid299068@asterisk/libpri-and-libss7-expert/Cresl1n) |
| 14:45.00 | *** mode/#asterisk-dev [+o cresl1n] by ChanServ |
| 14:48.58 | coreyfarrell | all seems reasonable to me |
| 15:31.24 | bford | hey everyone, looking for some ideas on how to go about storing some info. currently using AstDB to see if a file has been downloaded so that we don't have to download it again. using the URL to derive a hash to store the other info. at the minimum it needs to store expiration and file path. trying to avoid having this stored in memory since it will be dealing with certificates and could grow very large. thoughts? |
| 17:18.55 | *** join/#asterisk-dev elcontrastador (~textual@70-90-215-98-BusName-ca.sacra.hfc.comcastbusiness.net) |
| 17:27.48 | seanbright | bford: doesn't the bucket stuff do all of that already? |
| 17:28.30 | seanbright | is this a 13+ thing or a master+ thing? |
| 17:29.23 | seanbright | assuming master+, i would just mimic (or re-use?) res/res_http_media_cache.c |
| 17:51.58 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@2a01cb0583d31d00f4d7ddd1bc0987bc.ipv6.abo.wanadoo.fr) |
| 17:51.58 | bford | seanbright: it's for STIR/SHAKEN, which is probably not going in 13 |
| 17:51.58 | bford | i believe media_cache stores all the bucket files in a container in memory though, correct? |
| 18:10.20 | seanbright | bford: potentially... but it also puts it in astdb |
| 18:10.38 | seanbright | actually... no? |
| 18:10.46 | seanbright | not that actual files, no |
| 18:11.02 | bford | yeah, the files i'm storing on disc (ast_config_DATA_DIR) |
| 18:11.03 | seanbright | the files are stored on disk (in /tmp) |
| 18:11.09 | bford | storing the extra details in AstDB |
| 18:11.26 | seanbright | right, which is what res_http_media_cache is doing |
| 18:11.31 | seanbright | except a different dir |
| 18:12.18 | seanbright | certainly seems worth the time to me to look at res_http_media_cache and the bucket API and see if it was usuable before building something new |
| 18:12.23 | seanbright | just my opinion |
| 18:12.35 | seanbright | usable* |
| 18:13.04 | bford | that's what i was using as my reference point for what i'm doing now, but probably need to just not have the ao2 container and bucket files and just use AstDB |
| 18:13.05 | bford | my only concern was cluttering AstDB |
| 18:13.44 | seanbright | i mean, it's a RDBMS |
| 18:14.00 | seanbright | and it already sucks, can't make it much worse |
| 18:14.03 | seanbright | heh |
| 18:14.13 | bford | :P |
| 18:14.27 | bford | fair point |
| 18:16.02 | seanbright | i think if we find that astdb is not adequate as a metadata cache for certificates, it's probably not a very good one for media files either and we should move to something else entirely |
| 18:16.25 | seanbright | anyway, just my opinion |
| 18:19.48 | *** join/#asterisk-dev jkroon (~jkroon@165.16.203.106) |
| 18:22.33 | bford | i've got an idea on how to limit the entries that actually go in so there's not useless clutter, so i think it should be a fine solution |
| 18:22.33 | bford | just wanted opinions on it, if there was a better way it could be done, etc etc |
| 18:23.16 | seanbright | hear me out, first you implement an on-disk b+tree... |
| 18:36.20 | bford | i like where this is going, tell me more |
| 18:36.47 | gtjoseph | you'll be sorry you asked that |
| 18:36.50 | gtjoseph | :) |
| 18:42.52 | bford | i'm trying to get him to commit to a full implementation by the end of the day, but don't tell him that |
| 18:43.02 | gtjoseph | :) |
| 18:45.01 | seanbright | database indexes are b+trees (or similar data structures) |
| 18:45.07 | seanbright | pretty fast to read/write |
| 18:45.23 | seanbright | implemented on a lifetime ago, no desire to do that again |
| 18:45.55 | seanbright | one* |
| 23:02.55 | *** join/#asterisk-dev CELYA_1 (~Thunderbi@lfbn-nan-1-2297-47.w92-139.abo.wanadoo.fr) |