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

[Emil Velikov]

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 ?
>>
>>
>> Thanks
>> Emil
>
> 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 :-)

-Emil