Open Ivshti opened 12 years ago
A simple patch to hack the problem (apply to message.js): (this is only a guideline, I guess there is a better place to put this code in)
14c14
<
---
>
59c59,75
< message.body = data;
---
>
> if (message.signature == "a{sv}") /* Hash map, a special case */
> {
> var map = {};
> data[0].forEach(function(pair)
> {
> var value = pair[1][1][0];
> if (! isNaN(value))
> value = parseInt(value);
> map[pair[0]] = value;
> });
>
> message.body = [map];
> }
> else
> message.body = data;
>
78a95
>
thanks, I was thinking about this. Some thoughts:
"A DICT_ENTRY works exactly like a struct, but rather than parentheses it uses curly braces, and it has more restrictions. The restrictions are: it occurs only as an array element type; it has exactly two single complete types inside the curly braces; the first single complete type (the "key") must be a basic type rather than a container type. Implementations must not accept dict entries outside of arrays, must not accept dict entries with zero, one, or more than two fields, and must not accept dict entries with non-basic-typed keys. A dict entry is always a key-value pair.
The first field in the DICT_ENTRY is always the key. A message is considered corrupt if the same key occurs twice in the same array of DICT_ENTRY. However, for performance reasons implementations are not required to reject dicts with duplicate keys.
In most languages, an array of dict entry would be represented as a map, hash table, or dict object."
Basically an a{s} where \ is a basic type is a hash. And yes, it must be accepted at any level, that did not occur to me.
The dbus type a{sv} (array of string -> variant pairs) is considered a dictionary, so it usually gets translated to a JS object by DBus clients. In this Dbus implementation, it remains an array of pairs (also arrays).