One more thing,

I have implemented something similar for the osd-command, but only csv , ASCII 
and HTML (simple table).

I did this by adding a complex struct table to libcmd.a, so that it is 
available to all commands linking to it.

ATM, it can only output simple tables (with one Header- and one Footer-line  
if given).

You can also sort by one column. 
E.g.
# ./vos partinfo afs14.rzg.mpg.de -ttype 1

Partition,FreeSpace,TotalSpace                                                  
/vicepa,120201568,1928200192                                                    
/vicepg,170753232,1702836224                                                    
/viceps,211810376,1597898752                                                    
/vicepw,27915468,235865600                                                      


# ./vos partinfo afs14.rzg.mpg.de -ttype 1 -tsort 2
Partition,FreeSpace,TotalSpace
/vicepw,27914820,235865600
/vicepa,120201568,1928200192
/vicepg,170753232,1702836224
/viceps,211810376,1597898752

Unfortunately, there is a problem ATM with my Yahoo-OpenID and gerrit, so I 
can't push it up there, but you can find the patches against master here:

/afs/ipp-garching.mpg.de/u/hanke/public/openafs/tabular_output.patch
/afs/ipp-garching.mpg.de/u/hanke/public/openafs/tabular_output_example.patch

Maybe we can integrate the xml output there ? I guess it should be possible.

Christof


Am Donnerstag, 6. Mai 2010 16:37:32 schrieb Andrew Deason:
> Just one thing...
>
> On Thu, 6 May 2010 15:01:45 +0200
>
> Sanket Agarwal <[email protected]> wrote:
> > On Wed, May 5, 2010 at 5:15 PM, Steve Simmons <[email protected]> wrote:
> > > /* Print value of spare3 field as integer */
> > > if ( type == RAW )
> > >    fprintf( STDOUT, "%spare3\t\t %d (Optional)\n", value );
> > > else if ( type == XML )
> > >    fprintf( STDOUT, "\t\t<spare3>%d</spare3>\n", value );
> > > else if ( type == CSV )
> > >    fprintf( STDOUT, "%,%d", value );
>
> Once we get to multiple output formats, I'd have thought this to turn
> into arrays of function pointers, instead of several if/else ladders (a
> la the cache types in the client code). So you'd have something like
>
> output_type->print_spare3("spare3", value);
>
> And you'd define
>
> static struct vos_output raw_output = {
>       /* ... */
>       .print_spare3 = print_raw_int_optional,
>       /* ... */
> };
>
> static struct vos_output xml_output = {
>       /* ... */
>       .print_spare3 = print_xml_int,
>       /* ... */
> };
>
> static void
> print_raw_optional(const char *name, int value)
> {
>     fprintf(STDOUT, "%s\t\t %d (Optional)\n", name, value);
> }
>
> /* ... etc */
>
> Or whatever. And use one of those structs depending on the -format
> argument.
>
> So, you don't have entirely separate enumeration functions, etc. What
> values you print and in what order are the same for all; the only
> difference is how they are output. In theory I think the problems in
> e.g. SubEnumerate that Steve mentions are surmountable if you just give
> each callback function enough context.
>
> But I don't know, a lot of the logic is still scattered, so I don't know
> how much better that would be. Just a thought.

Reply via email to