On 02/14/2015 09:22 AM, Emil Velikov wrote: > On 13 February 2015 at 02:22, Frank Henigman <[email protected]> wrote: >> On Thu, Feb 12, 2015 at 5:44 AM, Emil Velikov <[email protected]> >> wrote: >>> On 12 February 2015 at 02:01, Chad Versace <[email protected]> wrote: >>>> On 02/10/2015 01:20 PM, Frank Henigman wrote: >>>>> On Tue, Feb 10, 2015 at 4:08 PM, Frank Henigman <[email protected]> >>>>> 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.
signature.asc
Description: OpenPGP digital signature
_______________________________________________ waffle mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/waffle
