Mark Michelson wrote: > A while back, a discussion of a "blinky lights" proposal appeared on > this list [1]. A wiki page [2] was created as a result of the discussion. > > We're now at the point where we plan to implement externally-initiated > MWI in ARI and AMI. While the actual ARI approach has been agreed upon, > the under the hood aspects have not been discussed yet, so I want to > talk about it some. > > The current plan is to have Asterisk be a target for MWI updates. > Asterisk can be told that the number of messages for a given mailbox has > updated, and Asterisk will in turn notify interested parties (such as > SIP phones) of the change. Asterisk will also persist the data (using > sorcery) so that the data will be accessible if Asterisk is restarted. > The current MWI state can also be retrieved externally. What worries me about persisting this information is keeping it in sync with the outside world. If a mailbox goes away externally and the Asterisk instance is not running now the application has to do one of the following: 1. Keep a log of this fact and then ensure it is removed from Asterisk when it starts up 2. Destroy with hate any mailboxes it doesn't know about when Asterisk starts up (what about other applications?) That seems like a lot of work, and potentially issue prone which brings me to... Why are we persisting at all? Since this is completely externally driven there's going to be a chance no matter what that the information is stale. I would argue that not persisting and letting the external application feed it back in is better. This gives you a guarantee that the state is the same. Thoughts? -- Joshua Colp Digium, Inc. | Senior Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: www.digium.com & www.asterisk.org
