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

[Emil Velikov]

On 17/02/15 19:18, Chad Versace wrote:
> On 02/14/2015 09:22 AM, Emil Velikov wrote:
>> On 13 February 2015 at 02:22, Frank Henigman <fjhenigman at google.com> wrote:
>>> On Thu, Feb 12, 2015 at 5:44 AM, Emil Velikov <emil.l.velikov at gmail.com> wrote:
>>>> On 12 February 2015 at 02:01, Chad Versace <chad.versace at intel.com> wrote:
>>>>> On 02/10/2015 01:20 PM, Frank Henigman wrote:
>>>>>> On Tue, Feb 10, 2015 at 4:08 PM, Frank Henigman <fjhenigman at google.com> wrote:
>>>>>
>>>>>> Looks like Issue #3 is the format of the information.  I thought it
>>>>>> was given we should duplicate existing glxinfo/eglinfo/etc as closely
>>>>>> as possible, in order to be a drop-in replacement, but if I follow the
>>>>>> suggestions Chad made on github
>>>>>> (https://github.com/fjhenigman/waffle/commit/d0b45bb9850e6ae29ee379a2d3e8ba14afc1b872)
>>>>>> we'll be diverging.  "Improving" on existing tools is ok with me - I
>>>>>> don't have a huge investment in code to parse their output - but I
>>>>>> wonder if others feel differently.
>>>>>
>>>>> (+Jordan, +Dylan, questions below)
>>>>>
>>>>> Oh, when I made those Github comments, I didn't know you were trying to
>>>>> duplicate glxinfo output verbatim. Now I understand why the GLX lines
>>>>> look so different from wflinfo's current output.
>>>>>
>>>>> glxinfo wraps long lines for extension strings and separates extension names with commas.
>>>>> wflinfo intentionally prints extensions strings in their original form: single line,
>>>>> extension names separated by spaces. If I recall correctly, Jordan and Dylan wanted
>>>>> that format so that consumers who parsed wflinfo text output would be guaranteed a stable
>>>>> format.
>>>>>
>>>>> If wflinfo has mixed line formats (some lines are comma-separated and wrapped, some
>>>>> are space-separated), I fear that may cause problems for already-existing consumers.
>>>>> Dylan, Jordan, do you have an opinion here? Does this really matter?
>>>>>
>>>> The above are some examples why I am doubtful about adding such
>>>> function in waffle.
>>>>
>>>> One might want the extensions listed in alphabetic order, another to
>>>> have them one per line, another will likely be interested the client
>>>> extensions, or maybe the server ones, the GLX/CGL/WGL/EGL version only
>>>> ?
>>>>
>>>> Imho in order for one to get some flexibility I would opt for query
>>>> mechanism for issue 1.
>>>>
>>>> Chad, genuine question, can you please describe how having a string is
>>>> more extensible ?
> 
>>> I'm sold on easy parsing and wflinfo compatibility over {glx,egl}info
>>> compatibility.  There's no reason we can't have everything actually.
>>> The parameter I proposed could be used to select output format: match
>>> glxinfo, match older wflinfo, latest and easiest-to-parse, etc.
>>> I don't mean to answer for Chad, but the nice thing about returning a
>>> string is we can tweak it without changing the api, and maybe without
>>> breaking existing parsers (at least not badly).  You could say this is
>>> just a fuzzy and therefore useless kind of api, but that's "glass half
>>> empty" thinking.  (^:
> 
>>> I think a string is a good start.  We can lock in the format(s) if and
>>> when we choose, it in no way hinders later attempts at something
>>> fancier, and it shouldn't be hard to keep the string for compatibility
>>> after something fancier is available.
> 
>> I never meant the above as "this is a terrible idea", but more of "it
>> might take a while to reach a consensus about the format, stability of
>> it, etc.". As long as people are ok that most/some of the points are
>> on the trivial side, I'm happy.
>>
>> Just that I cannot shake away my "gift" of seeing the negative
>> effects/impact something might cause. Sorry if I went too crazy :-)
> 
> I think Frank explained the reasons well why exposing a string is
> a flexible, (mostly) future proof API. At the risk of repeating him...
> Exposing the info in an easily parseable string with a well-defined format
> means that, whenever wflinfo wishes to exposes more info, Waffle doesn't
> need to expose additional query API. We reduce API churn.
> And any well-behaved consumer will ignore
> fields it doesn't recognize during parsing. If we ever want to expose the info
> in a fancier way (json, xml, wrapped-to-80-columns, whatever), all that's
> needed is that Waffle expose a new enum token for that format, and the user
> requests the format like waffle_display_print_info(format=json).
> 
> It's extensible because it allows the producer to produce new info that the
> consumer does not recognize; and it allows the consumer to discard info
> it doesn't want or doesn't understand.
> 
I see my problem now - I'm picking too much on the "well-defined format"
and "well-behaved consumer will ignore fields".

Please ignore my bikeshedding, my OCD seems to be kicking in :-P

-Emil