Ben Pfaff <[email protected]> writes:

> On Wed, Dec 07, 2016 at 01:08:43PM -0500, Aaron Conole wrote:
>> Ben Pfaff <[email protected]> writes:
>> 
>> > On Wed, Dec 07, 2016 at 10:55:54AM -0500, Aaron Conole wrote:
>> >> Adds a new --format="xx={0},..." to the table library, which allows
>> >> users to make table output formats to match their own needs.
>> >> 
>> >> Signed-off-by: Aaron Conole <[email protected]>
>> >> ---
>> >> v1 url:
>> >>     
>> >> https://mail.openvswitch.org/pipermail/ovs-dev/2016-November/325235.html
>> >> 
>> >> TODO: Still needs unit tests to check the format strings
>> >>       One thing I want to do is put in the idea of string length to the
>> >>       grammar.  Probably will be a few other additions (ex: text which is
>> >>       omitted when the corresponding column value is empty).
>> >> 
>> >> NOTE: Submitted for early feedback
>> >
>> > Can you give an example of a use case?  If we're going to add this
>> > feature for formatting, I'd like to know that it's going to be genuinely
>> > useful to users.
>> 
>> Yes, sorry - I should have re-included my previous cover letter;
>> 
>> I am currently asked by some openstack folks to aid with 'debugability'
>> - specifically, they want a change to the openflow printing such that
>> they have data like:
>> 
>> COL1    COL2    COL3
>> ====    ====    ====
>> 
>> They want to choose the columns 'as-needed', and I think they also want
>> to change the formats.  Rather than code up multiple custom styles, I'd
>> like to just give them the ability to change output formats as they
>> wish.
>
> I guess it just sounds very similar to --format=table.

Agreed, this specific format is.

>> To accomplish this, I'm going down the following route:
>> 
>> 1. Add formatting option to the lib/table.{c,h}, such that we can
>>    still express the existing output.
>> 
>> 2. Change ofp-print to use a table for flow dumping, with a default
>>    format that preserves the current format, and the option of changing
>>    the format.
>
> #2 is interesting.

I don't currently see how to implement #2, while preserving the existing
output, unless I implement #1.  Is there a way to accomplish this that
I'm missing?  If not, is #2 compelling enough to accept #1?

Thanks for your time and for looking at this, Ben.
_______________________________________________
dev mailing list
[email protected]
https://mail.openvswitch.org/mailman/listinfo/ovs-dev

Reply via email to