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 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




[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