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). _______________________________________________ waffle mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/waffle
