Re: Standardization of Case for ARI URIs

[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]

 






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@lists.digium.com
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

_______________________________________________
asterisk-app-dev mailing list
asterisk-app-dev@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev

[Index of Archives]     [Asterisk SS7]     [Asterisk Announcements]     [Asterisk Users]     [PJ SIP]     [Linux ARM Kernel]     [Linux ARM]     [Linux Omap]     [Fedora ARM]     [IETF Annouce]     [Security]     [Bugtraq]     [Linux]     [Linux OMAP]     [Linux MIPS]     [ECOS]     [Linux API]

  Powered by Linux