Hi all, I know I'm probably stirring up a hornet's nest with this question/comment but I've spent the last few days working on a PHP-based class for the manager interface as we're preparing for a pretty big upgrade at our call center and I'm revamping all of the management apps I've written. I can connect to the manager interface and send query strings back and forth all day long, but I'm having issues when it comes to parsing the return data. My issue isn't a PHP one, but rather issues with the consistency of the Manager interface return values. For instance, for the built in actions such as Login, SIPPeers, QueueStatus (the three that I will be calling the most) NONE of those three has a standard return value. Login doesn't return an Event: LoginComplete flag, so the login function can't use the generic Action function I've written. SIPPeers returns an additional line after Event: PeerlistComplete, and Peerlist != SIPPeers (meaning the action and eventcomplete flags should match, IMHO). The way QueueStatus returns data is the ideal, the action flag (QueueStatus) has a corresponding complete tag (QueueStatusComplete) and I can (fairly) easily parse the return data by tacking 'Complete' onto the action flag. I just wanted to see what everyone else though of coming up with a standard for ALL manager commands so building applications to hook into Asterisk isn't a crap shoot like it is now. My initial proposal: Any $action has a corresponding $actionComplete event (ie SIPPeers would be SIPPeersComplete instead of PeerlistComplete) The ActionComplete event is the LAST line for any return Like I said, I'm sure this will ruffle some feathers and that is not my intent, maybe I'm missing something here so please (kindlly) inform me if I am. -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20081222/d5bdceb2/attachment.htm
On Mon, Dec 22, 2008 at 09:04:13AM -0600, Wesley Haut wrote:> Hi all, > > I know I'm probably stirring up a hornet's nest with this question/comment > but I've spent the last few days working on a PHP-based class for the > manager interfaceIsn't there one already?> as we're preparing for a pretty big upgrade at our call > center and I'm revamping all of the management apps I've written. I can > connect to the manager interface and send query strings back and forth all > day long, but I'm having issues when it comes to parsing the return data. > My issue isn't a PHP one, but rather issues with the consistency of the > Manager interface return values. > > For instance, for the built in actions such as Login, SIPPeers, QueueStatus > (the three that I will be calling the most) NONE of those three has a > standard return value. Login doesn't return an Event: LoginComplete flag, > so the login function can't use the generic Action function I've written.A *Complete even is sent as and end of a series of events. e.g. SIPPeers retuns a separate event for each peer and hence you need an event to tell you that the series is done. For Login, Ping and whatever you know you should not expect further events to follow after the initial reply.> SIPPeers returns an additional line after Event: PeerlistComplete, and > Peerlist != SIPPeers (meaning the action and eventcomplete flags should > match, IMHO). > > The way QueueStatus returns data is the ideal, the action flag (QueueStatus) > has a corresponding complete tag (QueueStatusComplete) and I can (fairly) > easily parse the return data by tacking 'Complete' onto the action flag. I > just wanted to see what everyone else though of coming up with a standard > for ALL manager commands so building applications to hook into Asterisk > isn't a crap shoot like it is now. > > My initial proposal: > > Any $action has a corresponding $actionComplete event (ie SIPPeers would be > SIPPeersComplete instead of PeerlistComplete) > The ActionComplete event is the LAST line for any return > > Like I said, I'm sure this will ruffle some feathers and that is not my > intent, maybe I'm missing something here so please (kindlly) inform me if I > am.For a larger audince of such proposals, try the -dev list . Be sure to refer to the trunk version. Note, however, that any change to the manager interface may break existing programs. -- Tzafrir Cohen icq#16849755 jabber:tzafrir.cohen at xorcom.com +972-50-7952406 mailto:tzafrir.cohen at xorcom.com http://www.xorcom.com iax:guest at local.xorcom.com/tzafrir
> Isn't there one already?Yeah, but none of them have worked for me...maybe their way of doing things is just different from my approach but I wasn't happy with any of the existing classes. I wasn't planning on releasing my code to the wild (I'm not a programmer by trade I just play one on TV).> A *Complete even is sent as and end of a series of events. e.g. SIPPeers > retuns a separate event for each peer and hence you need an event to > tell you that the series is done. For Login, Ping and whatever you know > you should not expect further events to follow after the initial reply.Um, not exactly. I just ran a SIPPeers on the CLI via telnet and each of the PeerEntry events does not have a Complete flag, just the double return. I guess what I was after was a standard way to finalize the larger event as a whole, and keep the existing double line return for separating the "individual" events. Again, maybe I'm going about this the wrong way as well.> For a larger audince of such proposals, try the -dev list . > Be sure to refer to the trunk version. Note, however, that any change to > the manager interface may break existing programs.Thanks, I'll wait until I've gotten further along on my project before bothering the devs <http://iax:guest at local.xorcom.com/tzafrir> -------------- next part -------------- An HTML attachment was scrubbed... URL: http://lists.digium.com/pipermail/asterisk-users/attachments/20081223/cdfa7925/attachment.htm