On 13-10-21 11:54 AM, Daniel Jenkins wrote: > On Mon, Oct 21, 2013 at 4:47 PM, Matthew Jordan <mjordan at digium.com> wrote: > >> >> On Mon, Oct 21, 2013 at 10:05 AM, Daniel Jenkins <dan.jenkins88 at gmail.com>wrote: >> >>> >>> On Mon, Oct 21, 2013 at 3:55 PM, Joshua Colp <jcolp at digium.com> wrote: >>> >>>> Daniel Jenkins wrote: >>>> >>>>> Is this to put a channel on hold/answer etc or to find out what state >>>>> the channel is in? >>>>> >>>> >>>> It's to put a channel on hold, instruct it to indicate ringing, etc. >>>> >>>> >>>> -- >>>> 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 >>>> >>>> ______________________________**_________________ >>>> asterisk-app-dev mailing list >>>> asterisk-app-dev at lists.digium.**com <asterisk-app-dev at lists.digium.com> >>>> http://lists.digium.com/cgi-**bin/mailman/listinfo/asterisk-**app-dev<http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev> >>>> >>> >>> >>> Oh right OK, I would agree with Paul on this one, >>> >>> One, the api is being designed partially so that non telephony people can >>> get into this, I didn't know what indicate meant in this context >>> >>> I would have this as a PUT (you're updating the state of that channel as >>> such) and have /ari/channel/{id}/hold (or whatever the prefix is) etc >>> >>> This is very clear, you're updating a channel to be in a hold state/ >>> you're telling the channel to answer etc. >>> >>> so +1 to Paul >>> >>> >> Before we decide to obliterate /indicate, do we foresee a need for other >> indications, e.g., /busy, /congestion, etc.? These are more in the >> "telephony" concepts subdomain, and are really different ways to destroy a >> channel. I'd prefer to not have them at all, honestly - the fact that you >> are disposing of a channel is all you should really care about through the >> API. Playing a particular tone when that occurs feels more like an optional >> detail, and not a true separate operation. But I'd hate to have a >> proliferation of similar concepts as separate operations when they make >> more sense grouped together. >> This was one of the reason I was trying to suggest, if we do expose more / all, I'd have to have /congestion /ring. /noanswer for each one. But if /indicate was alive, it would just be a reason varaible passed. >> Follow up: how ugly is it to have a parameter passed to DELETE? >> > > Not ugly at all! > > Especially when the BODY issue gets worked on, you'd have a JSON object > with the extra params > > This is definitely how I'd deal with the many iterations of how you could > hangup > > +1 > I've been trying to find a solution to this issue too. I can't really find a best pratice for it either. Unless there is a specific reason NOT to add parameters to a DELETE, I'm fine with passing them. -- Paul Belanger | PolyBeacon, Inc. Jabber: paul.belanger at polybeacon.com | IRC: pabelanger (Freenode) Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger
