Hi Willy,
this patchset seems to have stalled.
I'd like to find a way to revive it.
On Sun, Jan 08, 2017 at 11:52:46AM +0100, Simon Horman wrote:
> Hi Willy,
>
> On Sun, Jan 08, 2017 at 07:37:24AM +0100, Willy Tarreau wrote:
> > Hi Simon,
> >
> > On Wed, Jan 04, 2017 at 09:37:24AM +0100, Simon Horman wrote:
> > > Hi,
> > >
> > > this short series is an RFC implementation of adding JSON format
> > > output to show (info|stat). It also adds a new show schema json
> > > stats command to allow retreival of the schema which describes
> > > the JSON output of show (info|stat).
> > (...)
> >
> > Thanks for this. I'm seeing in stats_emit_json_field_tags() that
> > you have to emit the names of the various types, scopes, etc...
> > I think this is the reason why you mention in patch 1 that it needs
> > to be updated if the structure evolves. Probably that we should put
> > these fields in an array declared just next to the enums. This way
> > the declaration will be a bit more centralized.
I see how that may make things more centralised in theory.
But in practice I wonder how it might work.
enum field_origin, for example, is declared in stats.h.
However, if I put something like the following into the same file
then it will be defined multiple times as the header file is included
in the source for multiple objects.
const char *field_origin_long_name[] = {
[FO_METRIC] = "Metric",
...
};
Of course I can move the above into a .c file but then it is no
longer centralised with the enum it relates to.
> > > Some areas for possible discussion:
> > > * Use of STAT_STARTED in first patch
> > > * Possible automatic generation of (part) of schema in 2nd patch
> > > * Improved documentation
> >
> > For now I don't see anything there which needs further discussion, and
> > nobody commented on your patches either, possibly indicating you're on
> > the right track. If you want I can merge this series, it will be easier
> > for you to update it later using incremental patches.
> >
> > > Some discussion of the size of JSON output is included as an appendix
> > > to the changelog of the first patch.
> >
> > I'd prefer to integrate this with your commit message because it's quite
> > useful as-is.
> >
> > Just let me know if you want the series to get merged or if you prefer
> > to respin it.
>
> I'd prefer if you merged the series as-is
> and I then provided incremental updates.
FWIW, I believe the series still applies cleanly on master.
