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

[Chad Versace]

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.

-------------- next part --------------
A non-text attachment was scrubbed...
Name: signature.asc
Type: application/pgp-signature
Size: 884 bytes
Desc: OpenPGP digital signature
URL: <http://lists.freedesktop.org/archives/waffle/attachments/20150217/72463693/attachment.sig>