Okay, so the consensus I'm hearing is to change from case sensitive throughout to case sensitive only for identifiers and resources, and leave everything else insensitive and lower case (including technology).
PREFIX: case insensitive
PATH: case insensitive
TECH: case insensitive, case determined by actual technology name, convention is all UPPERCASE, but either will match
RESOURCE: case sensitive, must match actual configured value.
ID: case sensitive, must match actual identifier
OPERATION: case insensitive
Going forward (all future ARI URIs), the standard then is that all portions of a URI are case insensitive except where they are identifiers or resource names where the case matters.
Unless I receive any objections to this plan, I will go ahead and implement this later (in the coming days) when I get to the originating issue.
On Tue, Jan 21, 2014 at 11:51 AM, Leif Madsen <lmadsen@xxxxxxxxxxxxxxxxxx> wrote:
I agree with Paul here. Lets assume we're working with a standard web
type interface and not have a preferred uppercase convention just
because "that's how Asterisk has always done it".
The preference should be for lowercase throughout, except for any
channel or peer identifiers which need to be case sensitive due to
naming conventions.
Leif.
Leif Madsen
-----Original Message-----
From: Paul Belanger <paul.belanger@xxxxxxxxxxxxxx>
Reply-to: Asterisk Application Development discussion
<asterisk-app-dev@xxxxxxxxxxxxxxxx>
To: Asterisk Application Development discussion
<asterisk-app-dev@xxxxxxxxxxxxxxxx>
Subject: Re: Standardization of Case for ARI URIs
Date: Mon, 20 Jan 2014 15:45:36 -0500
Personally, I prefer everything to be lower case when possible. So,
things like TECH, if PJSIP, pjsip, PjSiP, are all valid inside
asterisk, lets round down to pjsip. However, if ENDPOINT is case
sensitive in Asterisk, then expect the end user to enter it as such.
So using your example above:
127.0.0.1:8088/ari/endpoints/pjsip/200
or
127.0.0.1:8088/ari/endpoints/pjsip/FooBar
or
127.0.0.1:8088/ari/endpoints/pjsip/foobar
All return different endpoints.
Additionally, have we even considered embedding the actually resource
URL when we list an object in the return result? Then Asterisk can
tell the user exactly how to get a specific item in the list.
For example, we create a links: [] object, that would list the actual
URI for said item.
--
Lead UC Systems Engineer
c: +1-613-800-7610
http://thinkingphones.com
_______________________________________________
asterisk-app-dev mailing list
asterisk-app-dev@xxxxxxxxxxxxxxxx
http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
Scott Griepentrog
Digium, Inc · Software Developer
445 Jan Davis Drive NW · Huntsville, AL 35806 · US
direct/fax: +1 256 428 6239 · mobile: +1 317 507 4029
Check us out at: http://digium.com · http://asterisk.org
Digium, Inc · Software Developer
445 Jan Davis Drive NW · Huntsville, AL 35806 · US
direct/fax: +1 256 428 6239 · mobile: +1 317 507 4029
Check us out at: http://digium.com · http://asterisk.org
_______________________________________________ asterisk-app-dev mailing list asterisk-app-dev@xxxxxxxxxxxxxxxx http://lists.digium.com/cgi-bin/mailman/listinfo/asterisk-app-dev
