Luca Lesinigo wrote:
Il giorno 23/ago/08, alle ore 14:12, Krzysztof A. Adamski ha scritto:
How do you see a "global" switch to choose between human-
and machine- readable outputs? The commandline interface could
default to human and the API to machine. Something like:
func -m $host call $mymodules blah ---> machine-readable output
func -h $host call... ---> human-readable
output func $host call.... ---> human-readable output
I like the general idea but it is not going to work the way
you proposed. First of all, you are giving "-h" or "-m" argument to
func command line utility while it would be much easier to just
implement this in "call" cmd_module.
The actual data is returned by the module so you have to tell the
module in which way it should be returned.
Mine was just an example. Depends on where and how you want to put the
formatting code.
This can be done in various ways but it's important to think about
good one and use it in all modules.
the way I see it, it's a piece of information that relates to the
global func behavior, since the func caller would either want all
human-readable stuff or all machine-ready stuff. I'd implement it as a
func (meaning the actual command) switch (it could also affect locally
generated output like errors and whatever), and the the client would
inform the remote funcd daemon about its output preferences.
Patches are welcome.
I was sure of that :)
--
Luca Lesinigo
------------------------------------------------------------------------
_______________________________________________
Func-list mailing list
Func-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/func-list
The modules themselves should ideally return output that is not
formatted for humans, with overlord side modules used to print them.
This was the idea around the "func '*' show..." commands, though I don't
think anyone is really using them.
I don't like the idea of a "-h" as that essentially means each module
must make the "-h" distinction.
Ultimately, I'd like to see things like "show" fleshed out as an
alternative to "call" for commands that return output for humans. Call
should be viewed as the quick route to calling modules, but not the only
route... for instance, func-inventory is a tool built on /several/ func
commands, but call is just a simple way to call one of them. So, we
can build up this sort of functionality in things like "show" if need
be, or create other minion side modules that expose other different
functionality.
--Michael
_______________________________________________
Func-list mailing list
Func-list@xxxxxxxxxx
https://www.redhat.com/mailman/listinfo/func-list
