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

[Jordan Justen]

On 2015-04-10 07:05:32, Frank Henigman wrote:
> Sorry I let this thread get 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.

wflinfo would have prefered the STRING_POINTERS format, but I think
JSON would be fine there as well.

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

I like your arguments about JSON being more extensible than the
STRING_POINTERS. Plus, STRING_POINTERS is just annoying to try to
document. :)

> 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.

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

I'm interested to see how easily the subsystems of waffle can add
strings to the JSON output. Hopefully they don't need to know anything
about JSON, and can just make one or more calls to add a new key +
value array.

Maybe you can post an early RFC after you get it to work with one
item? (Assuming others are okay with the plan.)

Thanks!

-Jordan