[waffle] [wflinfo] [RFC] platform-specific info from wflinfo

[Chad Versace]

On Fri 10 Apr 2015, Jordan Justen wrote:
> On 2015-04-10 07:05:32, Frank Henigman wrote:
> > Sorry I let this thread get stale.

I apologise too for letting it go stale.

> > > On 02/20/2015 01:49 PM, Jordan Justen wrote:
> > >> My idea was just to define a one-time API that left presentation of
> > >> the strings to the user of the library. Therefore, the Core API
> > >> wouldn't ever need to change past that point. It was also an attempt
> > >> to make it fairly easy to iterate through the results.
> > 
> > I couldn't agree with this more.  I was being a bit lazy in my
> > thinking before but I've seen the light.
> > So we want the core to provide information in a form that can be
> > used/presented by the caller as they like.
> > So why not just provide JSON?  It's simple (just returns a string) and
> > future-proof (new key/value pairs can be added for those who want them
> > and ignored by others) and there are numerous libraries for processing
> > JSON.
> > I think it's the only core info API we need.
> 
> I could get on board with this. It does seem like a good enough API.
> Although I'm sure it'll make things a little more annoying for some
> consumers.
> 
> For example, an app might have just wanted to select the TEXT version,
> and dump it to some dialog box. Now, they'd have to deal with the JSON
> first.

I could get on board with this too. Having a canonical format makes
a lot of sense. And JSON is a sensible choice. (The only sensible
choices, I believe, are JSON and XML).

I also share Jordan's concern that JSON may cause some annoyance for
some consumers. But I think we can adopt a policy that accomodates all
consumers: "This is JSON. Just deal with it". JSON is an ubiquitous
format for exchanging text data, and every language (even Bash) has
easy-to-use JSON tools. So "Just deal with it" is a sensible policy in
my opinion.

> I don't know who might have preferred XML, but I'm thinking JSON/XML
> has a vi/emacs sort of rivalry going on... :)

Well said :)

I think XML is overkill for the Waffle data we're discussing. And plain
text is too unstructured. JSON feels just right.

> > Then wflinfo can be re-implemented (preferably in python) as something
> > that gets the JSON string from the library and presents it in one or
> > more ways similar to what wflinfo does now.
> 
> Hmm, I like python, so this seems attractive. :)
> 
> But, I don't like the thought of having to make python libraries be a
> wflinfo dependency.
> 
> > Those who are already parsing glxinfo or wflinfo output can continue
> > to do that, but will now have the option of parsing the JSON, which
> > should be more robust.  I think we can also make the raw JSON friendly
> > to simple grepping, with judiciously placed newlines.
> > If there are no objections to this plan, I'll work on an implementation.
> 
> I'm okay with going the JSON only route.

The JSON plan sounds good to me too.

> I think I'd prefer to not convert wflinfo to python.

I also hesitate to convert wflinfo to python. After we push all the
complexity of wflinfo.c into a library call, then wflinfo.c will largely
consist of argparsing and a minimal json parser. wflinfo.c will then be
so small that I don't expect to gain much benefit in moving it to
wflinfo.py. (I expect moving it to Python might make it *more*
complicated if its argparsing code attempts to be python-2-and-3
compatible).