On Mon, Mar 3, 2014 at 6:18 AM, Zubin Mithra <zubin.mit...@gmail.com> wrote:
> On Sun, Mar 2, 2014 at 4:30 PM, Philippe Ombredanne
> <pombreda...@nexb.com> wrote:
>> On Tue, Feb 25, 2014 at 5:57 PM, Zubin Mithra <zubin.mit...@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
------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works.
Faster operations. Version large binaries. Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
_______________________________________________
Strace-devel mailing list
Strace-devel@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/strace-devel
