[notmuch] RFC: output json from notmuch?
cworth at cworth.org
Mon Dec 14 14:30:45 PST 2009
On Sun, 13 Dec 2009 19:21:02 -0400, David Bremner <david at tethera.net> wrote:
> It would be nice to have more structured output from notmuch-show. I
> decided to investigate sexp (i.e. lisp) and json output.
> Then I found that json parsing is provided by the library json.el
> shipped with emacs23, so I decided to play with json a bit.
That sounds very promising. I wasn't aware this existed inside emacs
> I settled on the jansson library (http://www.digip.org/jansson/)
> because it seemed to have a sane api and documentation, but there are
> many choices. I'll follow up with the actual patch, but the idea is to
> replace the printfs in show_message with calls to set (key,value) pairs
> in a json object, and output it at the end.
I'm still not sure of the need to depend on a library just to *generate*
any particular format. I would expect that job to be so constrained as
to be almost trivial. I won't necessarily block a patch based on that,
but I think we should at least look at how easy it would be to just emit
the syntax manually.
> So, do people think this is a reasonable idea to persue?
I do, yes. The current lack of full quoting is an obnoxious bug.
> 1) it adds a dependency, but not a heavy one. jansson is about 300k
> installed on debian/i386
That might be acceptable. And we might rewrite the patch to avoid it as
well. I'd like to see what that would take.
> 2) It might mean that people using emacs22 might have to score
> json.el from somewhere; I'm not sure.
Currently, it sounds like notmuch is entirely unusable from emacs22, so
I'm really not too concerned about one more thing that requires emacs
> 3) There is some increase in memory use since the whole thread has
> to be built as a json object before being output.
Right. That would be another reason to just stream the output
manually. The syntax doesn't require things like knowing the size of an
array before emitting the first element, right?
> 4) Of course jansson is doing it's own reference counting memory
> managment, and not using talloc. But we already have glib...
It's not evil to not use talloc. So not an issue there.
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Size: 189 bytes
Desc: not available
More information about the notmuch