On Wed, Jan 22, 2014 at 6:15 AM, Daniel Jenkins <dan.jenkins88@xxxxxxxxx> wrote: > > > > On Wed, Jan 22, 2014 at 11:03 AM, Walter Doekes > <wjdoekes+asterisk-dev@xxxxxxx> wrote: >> >> On 22/01/14 11:37, Daniel Jenkins wrote: >>> >>> Oh go on then, I'll chip in a little more than just +1'ing Paul, >>> >>> URLs should be case sensitive, I think we've settled on that now >> >> >> No. I think we've settled on sensitive and lowercase whenever (easily) >> possible. And case sensitive for the parts that matter. >> >> Just because the RFC says that URLs are case sensitive, does not mean that >> the RFC forbids aliases. >> >> >> >>> I'd prefer for SIP technology and any technology to be lowercase in the >>> url but if that's a crazy amount of work right now, then I'm fine with >>> it being Upper, or whatever the technology is set to within Asterisk, >> >> >> The point is, that if you make the decision to stick with UPPERTECH you'll >> have a hard time switching later. >> >> If we settle for these rules, we are forward compatible with an optional >> lowertech future: >> >> - case sensitive (usually lowercase) everywhere, >> - except technology names, which are case insensitive and have an >> uppercase canonical form (for now) >> >> If we then later decide to make lowertech the canonical form -- for >> starters by updating lots of json output everywhere -- newer scripts that >> use lowertech will still work on older ari versions. >> >> >> Walter >> >> >> _______________________________________________ >> asterisk-app-dev mailing list >> asterisk-app-dev@xxxxxxxxxxxxxxxx >> http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev > > > Hi Walter, > > My point was that TECH should be whatever it is in Asterisk and should not > be case insensitive, it just makes working with it more complex - everything > should be case sensitive and lower where possible, in the case of an device > id or whatever then it should be what's set in Asterisk - but for URL > descriptors everything should be lower. > > In the grand scheme of things, you should never build your application with > knowledge you are guessing from your own knowledge - for example, the ARI > should list it's available technologies and you should use that list to then > construct URLs, or even better, for the result from the ARI when asking for > all technologies, to give you a list of urls that you can call for each > technology - let the API guide you to where it knows is correct. > > There's too much guessing for my liking when people communicate with APIs, > they take what they think they know and form their own logic around it - the > ARI should tell you everything and your client should be dumb, entirely dumb > when it comes to what it knows about Asterisk/ARI > > When you treat your application as dumb and rely on the ARI telling you > information like URLs to follow etc, the ARI could change things to upper or > lower or whatever tomorrow and your application wouldn't care one bit. > > You talk about how the RFC doesn't forbid aliases - but an alias is designed > to make something easier, how would allowing SIP and sip make things easier > if your application got the list of technologies from Asterisk itself? > > Dan > My turn to +1 Dan. Lets be honest, if this was behind an HTTP server (via Asterisk serving up the content) we wouldn't even be having this discussion. I think we are pretty much there, lower case URLS, only when model, tech, item, foo, is actually case sensitive, I think everybody is on board with that. -- Paul Belanger | PolyBeacon, Inc. Jabber: paul.belanger@xxxxxxxxxxxxxx | IRC: pabelanger (Freenode) Github: https://github.com/pabelanger | Twitter: https://twitter.com/pabelanger _______________________________________________ asterisk-app-dev mailing list asterisk-app-dev@xxxxxxxxxxxxxxxx http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
