I hope we consider creating a res_redis first, then base everything off that.  If a redis library can be used directly by any module that would fine but I'd like to see us avoid following the example of curl where everything uses a dialplan function to perform requests.  Dialplan functions should be for dialplan, in general I think they should not be used as internal API's.

On 12/22/2017 12:23 PM, Nir Simionovich wrote:

Well,

We can start with that implementation as a base for learning, and go from there. Looks like I have some homework for tonight.

Nir


On Fri, Dec 22, 2017, 18:44 Matt Fredrickson <cres...@digium.com <mailto:cres...@digium.com>> wrote:

    On Fri, Dec 22, 2017 at 10:23 AM, Ivan Poddubny
    <ivan.poddu...@gmail.com <mailto:ivan.poddu...@gmail.com>> 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
        <cres...@digium.com <mailto:cres...@digium.com>> wrote:



            On Fri, Dec 22, 2017 at 6:58 AM, Nir Simionovich
            <nir.simionov...@gmail.com
            <mailto:nir.simionov...@gmail.com>> 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
                <ab...@avissol.com <mailto:ab...@avissol.com>> 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
                    <nir.simionov...@gmail.com
                    <mailto:nir.simionov...@gmail.com>> wrote:

                    Hi All,

                    Following a discussion on JIRA
                    [https://issues.asterisk.org/jira/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
                    <http://www.greenfieldtech.net/>
                      (p) +972-73-2557799 <tel:+972%2073-255-7799>
                    (MSN):n...@greenfieldtech.net
                    <mailto:n...@greenfieldtech.net>
                      (m) +972-54-6982826 <tel:+972%2054-698-2826>
                    (GTALK):nir.simionov...@gmail.com
                    <mailto:nir.simionov...@gmail.com>
                      (f) +972-73-2557202 <tel:+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
                <http://www.greenfieldtech.net/>

                  (p) +972-73-2557799 <tel:+972%2073-255-7799>
                (MSN):n...@greenfieldtech.net
                <mailto:n...@greenfieldtech.net>

                  (m) +972-54-6982826 <tel:+972%2054-698-2826>
                (GTALK):nir.simionov...@gmail.com
                <mailto:nir.simionov...@gmail.com>

                  (f) +972-73-2557202 <tel:+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

--

Kind Regards,

  Nir Simionovich

GreenfieldTech

(schedule) http://nirsimionovich.appointy.com/

  (w)http://www.greenfieldtech.net <http://www.greenfieldtech.net/>

  (p) +972-73-2557799 (MSN):n...@greenfieldtech.net <mailto:n...@greenfieldtech.net>

  (m) +972-54-6982826 (GTALK):nir.simionov...@gmail.com <mailto:nir.simionov...@gmail.com>

  (f) +972-73-2557202 (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

Reply via email to