On Thu, Feb 12, 2015 at 5:44 AM, Emil Velikov <emil.l.veli...@gmail.com> wrote:
> On 12 February 2015 at 02:01, Chad Versace <chad.vers...@intel.com> wrote:
>> On 02/10/2015 01:20 PM, Frank Henigman wrote:
>>> On Tue, Feb 10, 2015 at 4:08 PM, Frank Henigman <fjhenig...@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.
_______________________________________________
waffle mailing list
waffle@lists.freedesktop.org
http://lists.freedesktop.org/mailman/listinfo/waffle
