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

[Chad Versace]

On 02/20/2015 01:49 PM, Jordan Justen wrote:
> On 2015-02-20 12:58:07, Chad Versace wrote:
>> On 02/17/2015 11:30 PM, Jordan Justen wrote:


>> For the sake of apps who want to dump the info to a log file or to
>> the console and get on
>> with their lives, I think the default output format should be a
>> single, giant string. But, as we're discovering in this conversation,
>> a single giant string might not be appropriate as a one-size-fits-all format.
>> I believe we can have it both ways, though, by adding some optional parameters
>> to the API.
>>
>>   void*
>>   waffle_display_get_info(struct waffle_display *dpy,
>>                           enum waffle_display_info_format format,
>>                           uint32_t flags);
>>
>> Then we have the ability to define API like this:
>>
>>    // Returns a single, string suitable for log output. The return value
>>    // must be cast to `char*`. One valid flag is currently defined for this
>>    // format, WAFFLE_DISPLAY_INFO_VERBOSE_BIT.
>>    waffle_display_get_info(dpy, WAFFLE_DISPLAY_INFO_FORMAT_SIMPLE, 0)
>>
>>    // Returns Jordan array of strings. The return value must be cast to `char**`.
>>    // One valid flag is currently defined for this format,
>>    // WAFFLE_DISPLAY_INFO_VERBOSE_BIT.
>>    waffle_display_get_info(dpy, WAFFLE_DISPLAY_INFO_FORMAT_JORDAN, 0);
>>    
>>    // Returns a JSON string. The return valud must be cast to `char*`. Two
>>    // flags are currently defined for this format: WAFFLE_DISPLAY_INFO_VERBOSE_BIT
>>    // and WAFFLE_DISPLAY_INFO_INDENT_BIT.
>>    waffle_display_get_info(dpy, WAFFLE_DISPLAY_INFO_FORMAT_JSON, 0);
>>
>> Of course, the "simple" and "jordan" formats will be the first ones implemented.
>> People can implement other formats in the future. (The JSON format, I'm just
>> using that as a hypothetical example.)
>>
>> Do you think this is a good compromise between usability and extensibility? Does
>> my proposal lack some important knob you think is needed? Or is my proposal just
>> overall a bad idea?
> 
> My idea was just to define a one-time API that left presentation of
> the strings to the user of the library. Therefore, the Core API
> wouldn't ever need to change past that point. It was also an attempt
> to make it fairly easy to iterate through the results.
> 
> One example of trouble we might get into could be
> WAFFLE_DISPLAY_INFO_FORMAT_GLXINFO. Meaning we try to comma separate
> and break lines.
> 
> Except, we wouldn't know the best line length to use for breaking
> lines. In that case it more likely the application could best format
> it. (Assuming it was able to read the console text resolution.)
> 
> But, I have to admit, your idea probably would be pretty helpful to
> some applications. For example, JSON would probably be used by piglit.
> 
> Assuming you don't think the string pointers output is too horribly
> complex to document, then this seems like a good set to consider:
> * WAFFLE_DISPLAY_INFO_FORMAT_STRING_POINTERS
> * WAFFLE_DISPLAY_INFO_FORMAT_TEXT
> * WAFFLE_DISPLAY_INFO_FORMAT_JSON
> * WAFFLE_DISPLAY_INFO_FORMAT_XML
> * WAFFLE_DISPLAY_INFO_FORMAT_CSV (Eh, I'm not sure I like this one.)
> 
> The last 4 would be easy to implement based on the first.
> 
> This set seems like enough where we could avoid the need to add any
> more formats.

That set looks good to me, except for CSV. I don't like CSV.

The name STRING_POINTERS is clunky, but I can't think of a better
alternative.

For a first pass, I think we should implement STRING_POINTERS and
TEXT. Then, soon after that, JSON. I consider XML a nice-to-have
right now, just because I don't want to think about schema versioning.