[MERGE] Output refactoring and XML integration into bzrlib

[Aaron Bentley]

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Sorry this conversation got lost.  We've been busy...

Martin Albisetti wrote:
> The main goal behind pushing this change in bzrlib is to be able to
> get xml output of *all* commands, mainly because bzr-eclipse uses
> this, and making users install an extra bzr plugin is not very
> user-friendly.

Perhaps you could expand on what bzr-eclipse uses it *for*?

> Another good reason is that svn also has xml output in it's core, and
> I'm sure we'll run into more then one use case from a potential
> project migration.

bzr has XML mostly in its storage formats.  For example, bzr revisions
are already stored as XML.  So your XML log is essentially doing a lossy
conversion from one XML format to another.  It seems redundant, and may
be counterproductive, since the XML logger may discard information you
later decide you want.

> This pushed us to review how bzr currently implements outputs, and how
> we could best build around that without changing (or breaking) the
> API. When we started to port the current bzr-xmloutput plugin code
> into bzrlib, we realized we had the opportunity to abstract the way
> output where handled, and pave the road for other types of outputs
> (html, csv, etc) via plugins that wouldn't require copying and pasting
> large chunks of code and overriding commands, making the code very
> hard to maintain.

It's not clear to me that this should be done at the command level at
all.  bzr is designed to guess what a commandline user wants it to do.
But bzr-eclipse should know precisely what it wants bzr to do.

By working at a layer below the commands, you'll get finer control and
less commandline-specific behavior.  You'll also be shielded from
changes in the behavior of the commandline UI.

It does not make sense to me that bzr-eclipse would want the exact same
behavior as the commandline UI.  I also don't understand why bzr-eclipse
would want the same output as the commandline UI, just packaged differently.

The only bzrlib clients I'm aware of that take your approach are
"difftools" and bzrtools "colordiff".  And they both have the same
reason:they extend the behavior of existing commands.

As for HTML and CSV output, I'd strongly suggest taking a wait-and-see
approach.  I would expect that HTML output can be much better than the
commandline output, especially for showing annotations or diffs.  I
usually take a rule-of-three approach to refactoring: until you've got
at least three examples of the repetition, it's harder to really come to
grips with the common factors.

> So now we have to decide which path to take. An easier, clearer
> implementation which lets us output XML or plain text, but still
> doesn't solve other types of outputs, or, go a step further and make
> some deeper changes to allow us to define a pluggable abstract
> interface for all output, and let the users/developers imaginations go
> wild on how they want bzr to talk to them.

I would really rather back up, and look at the design goals and use
cases.  Because right now, we're not really communicating.  Until I have
a better idea what you're trying to achieve, and why you're doing it the
way you are, I can't really speak intelligently about what the right
approach is.

Aaron
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.4.6 (GNU/Linux)
Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org

iD8DBQFHTwv80F+nu1YWqI0RAl4uAJ4gYnynSacoUEszfh3pFCNUnPmVugCfdQOX
vccRFwX2+uE0ieJeNlwBcNk=
=Yq2b
-----END PGP SIGNATURE-----