On Fri, Dec 22, 2017 at 10:23 AM, Ivan Poddubny <[email protected]> wrote:
> Hi, > > There is an out-of-tree implementation of func_redis: https://github. > com/tic-ull/func_redis. > I don't use it in production, but it worked fine for me on a test machine. > With slight modifications it works with Asterisk 13+. > Unfortunately, the project seems to be abandoned and the author did not > try to merge the code upstream. > Yeah, unless he submits it and goes through that process himself, we can't do a lot with it in the mainline Asterisk codebase. Matthew Fredrickson > > On 22 December 2017 at 16:54, Matt Fredrickson <[email protected]> wrote: > >> >> >> On Fri, Dec 22, 2017 at 6:58 AM, Nir Simionovich < >> [email protected]> wrote: >> >>> Abhay, >>> >>> Migrating astsb from SQLlite to redis isn't the topic here. I'm talking >>> adding a new type of storage engine. For example, func_redis, that will >>> implement the relevant key/value operations that are commonly used by >>> people. >>> >> >> I think doing it as func_redis instead of a sorcery backend is a good >> idea. >> >> I'm guessing there are a lot of people that can use it. It seems like >> having access to a redis like backend is a modern requirement for most big >> systems. >> >> Matthew Fredrickson >> >> Nir >>> >>> On Fri, Dec 22, 2017, 14:33 Abhay Gupta <[email protected]> wrote: >>> >>>> Hi All, >>>> >>>> I had a program where I have implemented a project using REDIS wherein >>>> the client is made using a socket library and no other third party client >>>> library in C . >>>> >>>> This REDIS database has 400 million records and performs extremely well >>>> though the memory requirement for such a large dataset goes to 48GB . So I >>>> strongly believe that for such key value pair REDIS will be the right >>>> choice for ASTDB. >>>> >>>> Regards, >>>> >>>> Abhay >>>> >>>> On 22-Dec-2017, at 5:52 PM, Nir Simionovich <[email protected]> >>>> wrote: >>>> >>>> Hi All, >>>> >>>> Following a discussion on JIRA [https://issues.asterisk.org/j >>>> ira/browse/ASTERISK-27383], I truly believe that >>>> adding a scaleable, robust and most importantly - accepted key/value >>>> store mechanism to the Asterisk dialplan >>>> is a worthwhile effort. >>>> >>>> Every, and I do mean every, Asterisk application requires a key/value >>>> store of some form. Most developers will >>>> basically butcher (would have used stronger words, but refraining from >>>> doing so) AstDB in the process, which will >>>> then result in a performance toll - specifically when dealing with a >>>> high capacity systems. >>>> >>>> Initially, I was under the impression this should be done as a >>>> sorcery module, but I'm not sure this is the >>>> correct approach or the required use case. >>>> >>>> I would like to hear if others believe this is a worth while effort? >>>> if others believe it is, I'll be ecstatic to >>>> work with others on this one (adding Redis support isn't as simple as >>>> it sounds). However, before I start >>>> working on something, I'd like to see if others believe this as >>>> strongly as I do. >>>> >>>> On the same note, I'll be in NYC second week of January - so if any >>>> of you are around that area and would >>>> like to combine forces to spear this - would love to do so. >>>> >>>> >>>> -- >>>> Kind Regards, >>>> Nir Simionovich >>>> GreenfieldTech >>>> (schedule) http://nirsimionovich.appointy.com/ >>>> (w) http://www.greenfieldtech.net >>>> (p) +972-73-2557799 <+972%2073-255-7799> (MSN): >>>> [email protected] >>>> (m) +972-54-6982826 <+972%2054-698-2826> (GTALK): >>>> [email protected] >>>> (f) +972-73-2557202 <+972%2073-255-7202> (SKYPE): >>>> greenfieldtech.nir >>>> >>>> ---------------------------------------------------------- >>>> Zero Your Inbox <https://mailstrom.co/referral/ARZJE> | >>>> Cloud >>>> Servers <https://www.digitalocean.com/?refcode=97eeea09917a> >>>> ---------------------------------------------------------- >>>> >>>> *Disclaimer:* >>>> This e-mail is intended solely for the person to whom it is addressed >>>> and may contain confidential or legally privileged information. Access to >>>> this e-mail by anyone else is unauthorized. If an addressing or >>>> transmission error has misdirected this e-mail, please notify the author by >>>> replying to this e-mail and destroy this e-mail and any attachments. >>>> E-mail may be susceptible to data corruption, interception, >>>> unauthorized amendment, viruses and delays or the consequences thereof. If >>>> you are not the intended recipient, be advised that you have received this >>>> email in error and that any use, dissemination, forwarding, printing or >>>> copying of this email is strictly prohibited. >>>> >>>> -- >>>> _____________________________________________________________________ >>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >>>> >>>> asterisk-dev mailing list >>>> To UNSUBSCRIBE or update options visit: >>>> http://lists.digium.com/mailman/listinfo/asterisk-dev >>>> >>>> >>>> -- >>>> _____________________________________________________________________ >>>> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >>>> >>>> asterisk-dev mailing list >>>> To UNSUBSCRIBE or update options visit: >>>> http://lists.digium.com/mailman/listinfo/asterisk-dev >>> >>> -- >>> >>> Kind Regards, >>> >>> Nir Simionovich >>> >>> GreenfieldTech >>> >>> (schedule) http://nirsimionovich.appointy.com/ >>> >>> (w) http://www.greenfieldtech.net >>> >>> (p) +972-73-2557799 <+972%2073-255-7799> (MSN): >>> [email protected] >>> >>> (m) +972-54-6982826 <+972%2054-698-2826> (GTALK): >>> [email protected] >>> >>> (f) +972-73-2557202 <+972%2073-255-7202> (SKYPE): >>> greenfieldtech.nir >>> >>> >>> ---------------------------------------------------------- >>> >>> Zero Your Inbox <https://mailstrom.co/referral/ARZJE> | Cloud >>> Servers <https://www.digitalocean.com/?refcode=97eeea09917a> >>> >>> ---------------------------------------------------------- >>> >>> *Disclaimer:* >>> >>> This e-mail is intended solely for the person to whom it is addressed >>> and may contain confidential or legally privileged information. Access to >>> this e-mail by anyone else is unauthorized. If an addressing or >>> transmission error has misdirected this e-mail, please notify the author by >>> replying to this e-mail and destroy this e-mail and any attachments. >>> E-mail may be susceptible to data corruption, interception, unauthorized >>> amendment, viruses and delays or the consequences thereof. If you are not >>> the intended recipient, be advised that you have received this email in >>> error and that any use, dissemination, forwarding, printing or copying of >>> this email is strictly prohibited. >>> >>> -- >>> _____________________________________________________________________ >>> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >>> >>> asterisk-dev mailing list >>> To UNSUBSCRIBE or update options visit: >>> http://lists.digium.com/mailman/listinfo/asterisk-dev >>> >> >> >> >> -- >> Matthew Fredrickson >> Digium, Inc. | Engineering Manager >> 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA >> >> -- >> _____________________________________________________________________ >> -- Bandwidth and Colocation Provided by http://www.api-digital.com -- >> >> asterisk-dev mailing list >> To UNSUBSCRIBE or update options visit: >> http://lists.digium.com/mailman/listinfo/asterisk-dev >> > > > -- > _____________________________________________________________________ > -- Bandwidth and Colocation Provided by http://www.api-digital.com -- > > asterisk-dev mailing list > To UNSUBSCRIBE or update options visit: > http://lists.digium.com/mailman/listinfo/asterisk-dev > -- Matthew Fredrickson Digium, Inc. | Engineering Manager 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA
-- _____________________________________________________________________ -- Bandwidth and Colocation Provided by http://www.api-digital.com -- asterisk-dev mailing list To UNSUBSCRIBE or update options visit: http://lists.digium.com/mailman/listinfo/asterisk-dev
