|
From: Ashley P. <as...@pi...> - 2009-08-15 09:41:52
|
On Sat, 2009-08-15 at 08:48 +1000, Nicholas Nethercote wrote:
> On Fri, Aug 14, 2009 at 1:15 AM, Ashley Pittman<as...@pi...> wrote:
> > a) Why do we still need --xml=yes, isn't it implied by
> > --xml-file=<file>? It would appear the --xml=yes option can be dropped
> > completely, if used without a XML output destination it aborts anyway.
> >
> > b) If I do specify --xml-file=<file> but not --xml=yes I get partial
> > output in the xml file.
> >
> > <errorcounts>
> > </errorcounts>
>
> The small amount of output in (b) looks like a bug.
Yes. Interestingly enough this output was both the two xml tags and a
number of new-lines. Point (f) appears to be a simple bug as well, the
log file qualifier goes to stdout instead of the xml log file.
> But I agree that the option behaviour is sub-optimal and inconsistent,
> esp. that you can specify --xml-file without --xml=yes and it'll
> continue.
>
> I'd suggest:
>
> - Allow --xml=yes for backward compatibility. If it's specified, then
> --xml-{file,socket,fd} also has to be specified
>
> - If --xml-{file,socket,fd} is given, --xml=yes doesn't have to be,
> and you get full XML output.
That would seem sensible to me, the error message if you specify only
--xml=yes says what extra steps you need to take to enable xml so should
be sufficient, I can see the reason for not wanting to drop the option
completely.
Did you have any thoughts on the other points I mentioned, either
getting both sets of output and ideally a way of getting a qualifier in
over the --{log,file}-socket options.
Ashley,
--
Ashley Pittman, Bath, UK.
Padb - A parallel job inspection tool for cluster computing
http://padb.pittman.org.uk
|