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