<html><head><meta http-equiv="Content-Type" content="text/html charset=iso-8859-1"></head><body style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><br><div><div>4 dec 2012 kl. 04:31 skrev David M. Lee <<a href="mailto:dlee@digium.com">dlee@digium.com</a>>:</div><br class="Apple-interchange-newline"><blockquote type="cite"><div style="word-wrap: break-word; -webkit-nbsp-mode: space; -webkit-line-break: after-white-space; "><blockquote type="cite" style="font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><span class="Apple-style-span" style="color: rgb(51, 51, 51); font-family: Arial, Helvetica, FreeSans, sans-serif; line-height: 17px; ">I also agree with Olle on the granularity of permissions of users within this API, but for a different reason, the AMI has basic granularity in terms of what it's able to do, which is used enormously, why wouldn't you do something similar within this new API system?</span></blockquote><div style="font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><br></div><div style="font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; "><div>Others in the thread have covered the problems we've had with AMI's granular permissions.</div><div><br></div></div><div style="font-family: Helvetica; font-size: medium; font-style: normal; font-variant: normal; font-weight: normal; letter-spacing: normal; line-height: normal; orphans: 2; text-align: -webkit-auto; text-indent: 0px; text-transform: none; white-space: normal; widows: 2; word-spacing: 0px; -webkit-text-size-adjust: auto; -webkit-text-stroke-width: 0px; ">I think I need to reword that requirement to be more clear. I'm not saying we'll never have any sort of authorization scheme with the new API. What we're getting at is that it's not a requirement for a v1 API, and we have the time to think through the use cases and get the permissions right.</div></div><br class="Apple-interchange-newline"></blockquote></div>For clarification: I did not say anything about the current AMI permissions. I just said what's been missing in AMI (and many parts of Asterisk) is a partitioning system connected to the authorization, so that one can do multihosting. <div><br></div><div>This affects many parts of the design of a new API and should be there from start. I think Tilghman's proposal of tags is a good one, and is similar to what we've done to hack the AMI. My originate setvar and Tilghman's channel variable event filters work hand in hand to add some sort of "group" or "partition" concept to AMI. This is not something one can add afterwards, I strongly feel it needs to be in the design specs from start.<div><br></div><div>/O</div></div></body></html>