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 <[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. > 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 _______________________________________________ waffle mailing list [email protected] http://lists.freedesktop.org/mailman/listinfo/waffle
