On 04/14/2015 12:11 PM, Matthew Jordan wrote:
<snip>
Yup.
SO!
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
1) Changing to a key-value store that can replicate data to remote instances
or
2) Allowing the AstDB to use a remote key-value store, thus allowing
multiple Asterisk boxes to share the same store.
I don't have any mechanical findings with the code you've written. It'll
work for what it's intended to do. However, I feel like it has a couple
of flaws with it:
1) As I already pointed out, it has the problem that data consistency
can be an issue.
2) For what it does, it's pretty heavy. It requires Stasis subscriptions
and SIP publications. If the key-value store is doing the lifting
itself, it's likely to be easier and the replication likely would run as
a separate process.
--
_____________________________________________________________________
-- 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
