On Wed, 2019-10-16 at 08:08 +0200, Ulrich Windl wrote: <snip> > > > > Why not replace "--weg-cgi" with "--output-format=cgi"? > > > > CGI output is identical to HTML, with just a header change, so it > > was > > logically more of an option to the HTML implementation rather than > > a > > separate one. > > > > With the new approach, each format type may define any additional > > options to modify its behavior, and all tools automatically inherit > > those options. These will be grouped together in the help/man page. > > For > > example, the HTML option help is: > > > > Output Options (html): > > --output-cgi Add text needed to use output > > in a CGI > > program > > --output-meta-refresh=SECONDS How often to refresh > > God bless the long options, but considering that the only thing that > is > refreshed in crm_mon's output is... well the output,,, why not just > have > --refresh or --refresh-interval.
One of the goals is to have options that are consistent across all tools. We came up with the "--output-" prefix to make it easy to avoid conflicts with existing/future tool options. However, I think you're right that it's confusing. I'm thinking that instead, we can reserve each of the format types as an option prefix. For example, for html it would become: Output Options (html): --html-cgi Add text needed to use output in a CGI program --html-stylesheet=URI Link to an external CSS stylesheet --html-title=TITLE Page title which I think is a little shorter and more intuitive. There are a few existing --xml-* options we'd have to work around but I don't think that's a problem. Does that make more sense? BTW we decided to get rid of --output-meta-refresh altogether, and just continue using the existing --interval option for that purpose. > Also it wouldn't be too har > d (if there's any demand) to allow suffixes like > 's' for seconds, 'm' for minutes, and most likely more do not make > sense for a > refresh interval. Actually it already does, it's just not in the help description. We'll update the help. <snip> > > > > When called with ‑‑as‑xml, crm_mon's XML output will be > > > > identical > > > > to > > > > previous versions. When called with the new ‑‑output‑as=xml > > > > option, > > > > it > > > > will be slightly different: the outmost element will be a > > > > <pacemaker‑ > > > > result> element, which will be consistent across all tools. The > > > > old > > > > XML > > > > > > Why not as simple "status" element? "-result" doesn't really add > > > anything > > > useful. > > > > We wanted the design to allow for future flexibility in how users > > ask > > pacemaker to do something. The XML output would be the same whether > > the > > request came from a command-line tool, GUI, C API client > > application, > > REST API client, or any other future interface. The idea is that > > <pacemaker-result> might be a response to a <pacemaker-request>. > > But most likely any response will be a kind of result, so why have > "result" > explicitly? Also as it's all about pacemaker, why have "pacemaker" in > it? > (Remember how easy it was to get rid of "heartbeat"? ;-)) > So my argument for "status" simply is that the data describes the > status. The idea is that if the output is saved to a file, someone looking at that file later could easily figure out where it came from, even without any other context. > > All of the format options start with "--output-" so we can reserve > > those option names across all tools. > > Do you actually have a big matrix of all options available across the > tools? > I'd like to see! Me too. :) Not yet, we just grep for a new option name we're thinking of using. That's why we went with the "--output-" prefix, it was easy to make them unique. :) -- Ken Gaillot <kgail...@redhat.com> _______________________________________________ Manage your subscription: https://lists.clusterlabs.org/mailman/listinfo/users ClusterLabs home: https://www.clusterlabs.org/