This is definitely the approach that I would prefer as well, as it makes integration with external software much easier.
- Brad On Thu, Apr 16, 2015 at 12:37 PM, Jeffrey Ollie <[email protected]> wrote: > On Wed, Apr 15, 2015 at 2:11 PM, Mark Michelson <[email protected]> > wrote: >> >> On 04/14/2015 12:11 PM, Matthew Jordan wrote: >>> >>> >>> The question is: is this change worth having, or should it be scrapped >>> in favour of some alternate approach that makes use of other >>> technology? My feelings won't be hurt if the answer is "ditch it and >>> do something else" - this was a fun piece of code to right on some >>> plane flights. On the other hand, I don't have any real interest in >>> writing an alternative approach, so if the expectation is that an >>> AstDB wrapper around RabbitMQ or Redis will magically appear if I hit >>> the delete key, that expectation is likely to be wrong. >> >> >> Personally, I like the idea of either >> >> 2) Allowing the AstDB to use a remote key-value store, thus allowing >> multiple Asterisk boxes to share the same store. > > > I think that it would be best to develop an interface to third-party > key-value stores and let them handle the hard bits. Personally, I like > CoreOS' etcd, but there are others that could be useful like ZooKeeper, > Consul or Redis. > > -- > Jeff Ollie > > > -- > _____________________________________________________________________ > -- 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
