Re: [RFC/PATCH v2 0/4] A new library for plumbing output (inc. current status)

From: Julian Phillips <julian@quantumfyre.co.uk>
Date: Apr 18, 2010, 21:46 UTC
Message-ID: <203d6cefd3cd1020eb94fbd3d5e25eae@212.159.54.234>
In-Reply-To: <20100417140053.GA10997@coredump.intra.peff.net>

On Sat, 17 Apr 2010 10:00:53 -0400, Jeff King <peff@peff.net> wrote:

> On Sat, Apr 17, 2010 at 03:02:39PM +0200, Jakub Narebski wrote:
> 
>> Something like that (please remember that it is still in vague

beginnings

Show 17 quoted lines

>> of an idea stage:
>> 
>>   OUT_OBJECT(
>>      OUT_FIELD("mode",   OUT_MODE, tree.mode), SP,
>>      OUT_FIELD("type",   "%s", tree.object.type), SP,
>>      OUT_FIELD("object", OUT_SHA1, tree.object.sha1), TAB,
>>      OUT_FIELD("file", OUT_FILE(sep), tree.filename), 
>>      sep
>>   );
> 
> Doing that would require variadic macros, which are a C99-ism. So you
> would have to do:
> 
>   OUT_OBJECT_START();
>     OUT_FIELD("mode", OUT_MODE, tree.mode); OUT_SP;
>     ...
>   OUT_OBJECT_END();

Also, backends such as JSON want to know which things are strings, and which are numbers - as they print differently. An XML backend may want to distinguish even more (though I guess that depends on the design).

Show 14 quoted lines

> which is not all that different from what Julian has now. I do think
> some type-specific conversions might be handy. They don't even need to
> be macros. E.g.,:
> 
>   void output_mode(struct output_context *oc, int mode)
>   {
>     output_strf(oc, "mode", "%06o", mode);
>   }
> 
> OTOH, looking over Julian's last patch series, there really aren't that
> many that would be generally applicable, and as you can see they only
> save a few characters, not even a line. A few bigger objects could be
> factored out, but he has already done that (e.g., see
> wt_porcelain_unmerged in his v2 3/4).

It might help standardise the output between commands if there were helper functions for some of the larger structures - e.g. commits. Though I don't think that those functions would be able to do legacy output, due to the current lack of cross-command output compatibility. I'm starting to see this with blame and diff-tree (and family), where they both want to output information about commits.

I think that maybe I need to design and document the output structure for common concepts - so that it would be possible to pass the output from any command to a common parser, with matching utility functions in the code. Though, I'm not sure if there actually are any common concepts that need outputting apart from commits.

Current Status --------------

I had been planning to post an updated series this weekend, but I'm too tired to attempt tidying things up for posting at the moment ... If you want to see the current state then my current mess is available at http://git.q42.co.uk/w/output.git.

A quick summary of main changes since v2:
  - backends are now in a subdirectory
  - blame, diff-tree, have --ouptut=... support for plumbing output
  - log has some support for --ouput=...
  - output library has extended API, including quoted strings and
is_structured_output function
  - backend API includes explicit functions for top-level items

-- 
Julian