Advanced and improved absolute paths decoding

[Philippe Ombredanne]

On Mon, Mar 3, 2014 at 6:18 AM, Zubin Mithra <zubin.mithra at gmail.com> wrote:
> On Sun, Mar 2, 2014 at 4:30 PM, Philippe Ombredanne
> <pombredanne at nexb.com> wrote:
>> On Tue, Feb 25, 2014 at 5:57 PM, Zubin Mithra <zubin.mithra at gmail.com> wrote:
>>> Hey all,
>>> I'm Zubin and I love low level systems programming! :)
>> [...]
>>> I had a look at the ideas list here[1] and found the idea on improved path
>>> decoding quite interesting and was hoping we could discuss it further on the
>>> mailing list.
>> While looking at path decoding is there other areas or ideas you could
>> consider too such as structured json output?
>
> I just had a second look at the ideas list and the discussions on the
> mailing list so far. Its quite interesting and I believe something
> that can fit in with the existing idea.
>
> Perhaps the following format makes sense? A call to :-
> open("/usr/lib/locale/UTF-8/LC_CTYPE", O_RDONLY|O_CLOEXEC) = -1 ENOENT
>
> could be represented in JSON as :-
> {
>    "call_one" : {
>       "fnname" = "open",
>       "arg1"     = "\"/usr/lib/locale/UTF-8/LC_CTYPE\"",
>       "arg2"     = "O_RDONLY|O_CLOEXEC",
>        "ret"       = "-1"
>    }
> }

Just curious, why would you use call_one? and arg1,arg2 v.s using  lists?
FWIW the above would not be valid JSON.
What about something like:
[
  {"fnname": "open",
   "args":  ["/usr/lib/locale/UTF-8/LC_CTYPE", "O_RDONLY|O_CLOEXEC"],
   "ret": "-1"
  }
]

or possibly (not sure which form I like best) using a more compact
entirely and positional list of lists:
[
    "open",
    "-1",
   [
        "/usr/lib/locale/UTF-8/LC_CTYPE",
        "O_RDONLY|O_CLOEXEC"
    ]
]

> Of course, this above example is oversimplified(And I'm not sure thats
> the best way to manage quoting to be honest, I'll put in some more
> thought).

I think that in the case of a JSON output, double quoting paths would
not be desirable and paths should be returned a simple JSON string

> In cases where a struct is passed as an argument, as in the case of a
> bind call we have,
> bind(3, {sa_family=AF_INET, sin_port=htons(7171),
> sin_addr=inet_addr("0.0.0.0")}, 16) = 0
>
> We could have "arg2" set to "{sa_family=AF_INET, sin_port=htons(7171),
> sin_addr=inet_addr("0.0.0.0")}" but I feel it defeats the purpose as
> parsing output itself would be more painful. Perhaps something like
> the following would be nice.
>
> {
>    "call_thirteen" : {
>       "fnname" = "bind",
>       "arg1"     = "3",
>       "arg2"     : {
>             "sa_family" : "AF_INET",
>             "sin_port" : "htons(7171)",
>             "sin_addr" : "inet_addr("0.0.0.0")"
>        },
>        "ret"       = "-1"
>    }
> }

This makes sense but same comment as above: why not using a combo of
objects and arrays (using JSON speak)?
and why not structuring everything that can be?
ie something along these lines?
[
    {
        "fnname": "bind",
        "args": [
            "3",
            {
                "sa_family": "AF_INET",
                "sin_port": {
                    "htons": "7171"
                },
                "sin_addr": {
                    "inet_addr": "0.0.0.0"
                }
            }
        ],
        "ret": "-1"
    }
]

--
Philippe Ombredanne