[Twisted-Python] t.trial.remote -- does anyone use it?

[glyph at divmod.com]

>PS: another approach (implemented in trial at some point, I think, but I
>don't believe I ever got buildbot to use it) was to jelly some status objects
>and fling them out stdout in the hopes of being picked up by whoever launched
>trial. This might have worked better, because one-way jelly over stdout
>wouldn't have involved a Selectable (unlike two-way PB over stdio), so the
>cleanup might not have stomped on it. However, I was uncomfortable with the
>potential version skew of the code creating these jellied objects (coming
>from twisted.trial) and the code that was hoping to interpret them (coming
>from buildbot). The pluggable Reporter allowed the buildbot to supply the
>code on both sides of the wire, which struck me as a better long-term
>solution.

The problem with this approach is that really, *everything* in trial ought to be going through the reactor, and cleanup will have to be smart enough to understand which objects shouldn't be cleaned up (generalizing the case of the waker, for example).

Pluggable reporters are indeed a worthwhile idea, but could we make them an actual plugin interface with twisted?  Passing classnames on the commandline is verbose and pretty gross IMHO (except for cases like the test-case-name, where you're actually referring to the user of the program's code) and it should use a domain-specific plugin name... aside from the aesthetic concern though, using plugins makes it possible to have 'trial --help' (or the Trial->Help menu option in your favorite twisted-enabled IDE...) list all possible reporter plugins, and to reduce confusion between import errors related to trial bugs and import errors related to plugins being unavailable or misspelled.