On Oct 16, 2013, at 1:20 PM, Paul Belanger <paul.belanger at polybeacon.com> wrote: > So, I actually tried this last night, using multiple channels but here > is the issue that I ran into with bulk. I have a list of channels, > some that we in stasis and some not, addChannels failed. However, I > was surprised to see that no actually channels made it into the > bridge, instead I got back a generic message about channels does not > exist. In general, channels need to be in Stasis() in order for ARI to work on them. For bulk operations, it's best to do 'all or nothing' as much as possible. There's no HTTP response code for "it sorta worked" :-) The error response should be more specific, listing the channels it had a problem with. Mind opening an issue for that in JIRA? > Of course, this now opens up the issue of how to tracking > which channel was the issue and generate error messages / return > codes. Now we are starting to move into more complex sceneries which > is all good, but now more and more logic has to be created to handle > it. When the complexity is overwhelming (such as is the case with the /dial operation), I agree. But this is a case where the complexity can be completely contained. The function for implementing a bulk add is currently ~30 lines of code. Adding failing channels to the error message would probably be another 10 lines of code. > So, going back to the point of single vs bulk, I think we should focus > on the single operation, have said library or application you are > working with take the hit and generate the additional request and once > we see how people are using the ARI, then work to optimize performance > issues but adding specific bulk functions. But we also need to be careful that we don't paint ourselves into a corner with our decisions. It's not about entirely about optimizing. It's also about keeping the API simple. And keeping it flexible for the future. The RESTful-purist method for adding/removing channels hinders the bulk add/remove use case dramatically. But the current API doesn't hinder anything; it just makes the REST purists cringe a little. > Because honestly, if we are saying the work lot need for additional > HTTP requests are going to hinder asterisk, then I think we have a > bigger issue at play. Then to me, we move http out side of asterisk > and write directly to the messagebus and have asterisk deal with it > then. We just built this thing. Don't give up on it yet! These are the same challenges you will have with any remote API, not just RESTful HTTP. -- David M. Lee Digium, Inc. | Software Developer 445 Jan Davis Drive NW - Huntsville, AL 35806 - USA Check us out at: www.digium.com & www.asterisk.org
