JSON-RPC 2.0 parameters: scalars only, no arrays + objects?
Vladimir Dzhuvinov
I've been using JSON-RPC 2.0 for over six months now, but still have
got questions :)
I'm working on JSONRPC2LDAP, a web service for giving AJAX browser
apps access to LDAP directories via JSON-RPC 2.0. The nature of LDAP
requires me to implement a number of methods where I need to pass
arrays/composite objects to a number of methods. It looks like the
JSON-RPC 2.0 standard allows only for JSON scalars to be passed as
method values. Is this so?
For example, I've got this method called "ldap.getEntry". If JSON
arrays/objects were allowed, I could have a call like this:
ldap.getEntry {"entryDN":"ou=users,uid=jbrown", "attributes":
["cn", "sn", "displayName", "uid"]}
Is this possible? Otherwise I will just resort to using scalars, e.g.
strings with delimiters like
ldap.getEntry {"entryDN":"ou=users,uid=jbrown", "attributes":"cn sn
displayName uid"}
~ Vladimir
--
Vladimir Dzhuvinov
www.dzhuvinov.com
Matt (MPCM)
should not work.
By method values do you mean parameters?
Perhaps an example of what your json-rpc request string looks like
would clear this up?
--
Matt (MPCM)
Vladimir Dzhuvinov
On Jan 4, 10:43 pm, "Matt (MPCM)" <wickedlo...@gmail.com> wrote:
> I am not entirely grokking what you posted, but I don't see why it
> should not work.
Good! It's just that the spec isn't explicit on kind of parameter
values are allowed and the examples I've seen use only JSON scalars.
> By method values do you mean parameters?
Sorry, yes, I meant parameter values
> Perhaps an example of what your json-rpc request string looks like
> would clear this up?
{
"id":0,
"method":"ldap.getEntry",
"params":{
"attributes":["cn","sn","displayName"],
"dn" :"uid=admin,ou=system"
},
"jsonrpc":"2.0"
Arne Blankerts
>
> On Jan 4, 10:43 pm, "Matt (MPCM)" <wickedlo...@gmail.com> wrote:
> > I am not entirely grokking what you posted, but I don't see why it
> > should not work.
> Good! It's just that the spec isn't explicit on kind of parameter
> values are allowed and the examples I've seen use only JSON scalars.
I'm not sure I get you...
Quote from the Spec/Proposal:
params
An Array or Object, that holds the actual parameter values for
the invocation of the procedure. Can be omitted if empty.
as well as:
4.2 Parameters (positional and named)
Parameters for a procedure call can be specified by-position, or
by-name.
* by-position: params MUST be an Array, containing the parameters
in the right order (like in JSON-RPC 1.0).
* by-name: params MUST be an Object, containing the
parameter-names and its values. The names MUST match exactly
(including case) the names defined by the formal arguments. The
order of the name/value-pairs is insignificant.
> > Perhaps an example of what your json-rpc request string looks like
> > would clear this up?
>
> {
> "id":0,
> "method":"ldap.getEntry",
> "params":{
> "attributes":["cn","sn","displayName"],
> "dn" :"uid=admin,ou=system"
> },
> "jsonrpc":"2.0"
> }
That would make it a name-based parameter, giving two parameters -
namely attributes and dn.
If you want those to be the actual object wrapped by the { }, you'd need
to make it a position based call and thus need to wrap it into an array:
...
"params":[{
"attributes":["cn","sn","displayName"],
"dn" :"uid=admin,ou=system"
}],
...
HTH
CYA Arne
--
Those who do not understand Unix
are condemned to reinvent it, poorly (Henry Spencer)
Lorenzo Pastrana
believe is intended here :
+ * by-position: params MUST be an Array, containing the VALUES
in the right order (like in JSON-RPC 1.0).
* by-name: params MUST be an Object, containing the
+ parameter-names and their VALUES. The names MUST match exactly
(including case) the names defined by the formal arguments. The
+ order of the names/VALUES-pairs is insignificant.
+ * Where VALUES are any valid json scalar, array or object
Any thought ?
Lo.
Matt (MPCM)
We keep using the word scalar to mean a non-structured (or non-
composite) value. But the word scalar seems to mean a great deal of
things in different contexts. As well as not having a clear meaning in
the negative, as in in non-scalar value.
As this is json based, it might be best use the phrasing from the
json.org site more closely. The site talks about json having
"structures", so saying a "non-structured value" would mean any none
object and none array value. The word scalar does not appear on the
site at all. The word 'primitive' is used in the RFC for json.
Would anyone object to me modifying the phrasing used to more closely
match those sources?
--
Matt (MPCM)
Jeffrey Damick
On Jan 5, 12:00 pm, "Matt (MPCM)" <wickedlo...@gmail.com> wrote:
> Sounds good to me. Could we change 'right' to 'expected' in your list?
I agree, expected sounds better.
> As this is json based, it might be best use the phrasing from the
> json.org site more closely. The site talks about json having
> "structures", so saying a "non-structured value" would mean any none
> object and none array value. The word scalar does not appear on the
> site at all. The word 'primitive' is used in the RFC for json.
>
> Would anyone object to me modifying the phrasing used to more closely
> match those sources?
yeah this would make it a lot clearer, good catch..
Robert Goldman
I'd prefer that the specification contain a definition of the term
"primitive value" and that we use "primitive" instead of
"non-structured," or "scalar."
Ideally the definition would list the primitive types, since in some
languages, e.g., "string" is a non-primitive type.
Best,
r
Vladimir Dzhuvinov
As for "scalar", I also find this somewhat confusing to describe
collectively the null, boolean, number and string datatypes. The word
"scalar" implies a quantity that cannot be resolved into components
and can vary in magnitude (scale). I don't see how null and strings
can fit into this description (boolean true/false may be regarded as
the simplest possible scalar).
I had a look at the JSON RFC-4627 and they do use "primitive" to
describe these basic data types. I think they call strings a primitive
data type because in JSON they aren't composed of more basic data
types (but may still be divided into smaller stings). In this sense
"basic data type" seems like a good candidate next to "primitive".
Lorenzo Pastrana
Sounds good to me. Could we change 'right' to 'expected' in your list?
Ok for this one, sounds better yes..
We keep using the word scalar to mean a non-structured (or non- composite) value.
http://en.wikipedia.org/wiki/Scalar_(computing)
But the word scalar seems to mean a great deal of things in different contexts.
http://www.google.fr/search?q=define%3Ascalar
As this is json based, it might be best use the phrasing from the json.org site more closely.
However, what we may be facing here is just the lack of "Definitions" section ...
Lo.
Robert Goldman
That would be great. I find the term "primitive" much more familiar in
the programming language context, and I bet others would too.
>
> However, what we may be facing here is just the lack of "Definitions"
> section ...
Agreed. I vote for adding one.
It would particularly help /me/, because while I'm a bit of a JS/ES
programmer, that's not my main preoccupation (I'm using JSON-RPC to work
with JS from other languages). Making sure my understanding of what,
e.g., is a "primitive" agrees with JSON-RPC, would really help (e.g., I
think of strings as arrays and have to make a conscious effort to
remember that they are primitives for JS).
Thanks for all your work on this!
Best,
r
Gaetano Giunta
> On 1/8/10 Jan 8 -9:57 AM, Lorenzo Pastrana wrote:
>
>> On Tue, 2010-01-05 at 09:00 -0800, Matt (MPCM) wrote:
>>
>>> Sounds good to me. Could we change 'right' to 'expected' in your list?
>>>
>> Ok for this one, sounds better yes..
>>
>>
>>> We keep using the word scalar to mean a non-structured (or non-
>>> composite) value.
>>>
>> And I believe we are right :D
>> http://en.wikipedia.org/wiki/Scalar_(computing)
>>
>>> But the word scalar seems to mean a great deal of
>>> things in different contexts.
>>>
>> Yes, as for linear algebra, physics, etc..
>> http://www.google.fr/search?q=define%3Ascalar
>>
>>> As this is json based, it might be best use the phrasing from the
>>> json.org site more closely.
>>>
>> I've been looking at Ecma-262 specs, and the notion there is 'language
>> Type' (Section 8) which includes Objects (which can be Arrays) so it
>> seems scalars aren't much a preoccupation there ... I still believe
>> scalar is unambiguous, but as the term is 'primitive' in json (rfc4627
>> line 37) it's ok for me to use primitive instead of scalar.
>>
> That would be great. I find the term "primitive" much more familiar in
> the programming language context, and I bet others would too.
>
for a long time with xmlrpc, where scalar values are clearly defined -
or maybe because the language I work with most is PHP, where scalar
types are also clearly defined... Afaik the term 'primitive type' is not
very much in use in the scripting-languages world.
Robert Goldman
Thank you very much for pointing this out. I hadn't realized that.
But I think "primitive" is standard.
The ecmascript standard, 4.3.2, defines "primitive value":
"A primitive value is a member of one of the types Undefined, Null,
Boolean, Number, or String. A primitive value is a datum that is
represented directly at the lowest level of the language implementation."
The word "scalar" seems to be used only in connection with text
encodings and unicode, where it has a special meaning.
Grabbing an old java book, I see a section on "Primitive Data Types,"
python and ruby doesn't have the distinction AFAICT between primitives
and non-primitive types. C uses "scalar" for primitives, but that makes
sense, because in C all the primitives /are/ scalars --- they are
numerical values because of the way C treats characters as just integers.
I wonder if "scalar" for "primitive" in scripting languages comes from
Perl, which is pretty non-standard in quite a bit of its jargon, since
it is inspired by natural language, rather than by conventional computer
programming language. I love perl to death, but I'm not sure I would
take it as a precedent for anything!
That's my argument for "primitive" versus "scalar." I think
"primitive" is a better term in languages where primitive and arithmetic
don't line up as neatly as they do in C. And I think for a JavaScript
based encoding, it makes sense to follow the Ecmascript spec jargon.
That said, I think the most important thing is to have a definition
section, and have consistent and clear usage.
Best,
R
Matt (MPCM)
I am in the process of editing and cleaning up the spec document.
Primarily making sure the definitions exist in the document and that
the same wording is used in different parts of the document. I am also
cleaning up the HTML, which google's editor likes to mangle the src so
it seems, but I am going to make sure we have a clean non-google-
groups mangled copy in the files section as well before I turn it back
to the group to review and revise further.
--
Matt (MPCM)
Lorenzo Pastrana
>>> And I believe we are right :D >>> http://en.wikipedia.org/wiki/Scalar_(computing) >>> >>>> But the word scalar seems to mean a great deal of >>>> things in different contexts. >>>> >>> Yes, as for linear algebra, physics, etc.. >>> http://www.google.fr/search?q=define%3Ascalar
The 'single value' meaning of scalar is language agnostic and actually comes from linear algebra where it names a 'single number' value as opposed to a vector (offset is a vector, it's magnitude is a scalar), by transposition computing adopted the term to name single values as opposed to objects, arrays etc. whether they are primitives or not ...>>> I wonder if "scalar" for "primitive" in scripting languages comes from Perl,
Primitive qualifies a Type
Scalar qualifies a Value
In Javascript the Number and String type, without being a primitive type (even if they are 'native' Javascript types, both are objects with methods etc.) have a scalar value and will result in a scalar property in a JSON construct.
JSON being a values matter and 'scalar' suffering no ambiguity in the value semantic field I feel we are just plain right to use this term.
... But as long as there is a definitions section ...
Lorenzo
Matt (MPCM)
(what we should use for shared editing) and another copy to the files
section. The Pages version does not want to let me keep the few style
tags I set, which do help with the visual separation in my opinion, so
you can see them in the files version.
JSON-RPC really is a spec about primarily two data structures (three
if you count the error object) and the rules around their processing
and handling. I kept most of the original document intact, while
adjusting the wording/style to unify the terms used and to more
closely reflect the simplicity of the spec. The definitions are under
the conventions section.
--
Matt (MPCM)
Vladimir Dzhuvinov
> I kept most of the original document intact, while
> adjusting the wording/style to unify the terms used and to more
> closely reflect the simplicity of the spec. The definitions are under
> the conventions section.
I liked it, the data type terms and their origin are very well
explained now!
--
Vladimir Dzhuvinov
www.dzhuvinov.com
Matt (MPCM)
help!
--
Matt (MPCM)