[Twisted-Python] Bloat (was Re: [Twisted-commits] DependentMultiService - chained start/stop of services in a sensible order)
glyph at twistedmatrix.com
Sun Apr 13 20:32:25 EDT 2003
-----BEGIN PGP SIGNED MESSAGE-----
This patch strikes me as unnecessary:
On Sunday, April 13, 2003, at 03:48 PM, etrepum CVS wrote:
> Modified files:
> Twisted/twisted/internet/app.py 1.89 1.90
> Log message:
> DependentMultiService - chained start/stop of services in a sensible
but I would like to discuss it and other patches like it. Not to pick
on bob here; there isn't really a policy on avoiding bloat in Twisted,
so it can't be said that this is a violation of anything in particular.
I just think we need one.
First, my question is: do we have more than one or two users who
actually need this functionality? If it's a real, present need for a
wide variety of applications, then much of this criticism does not
Addition of stuff like this strikes me as similar to the addition of
complicated preference panels to GNOME to work around core usability
problems, which only created a new usability problems.
This patch is a band-aid on an already crummy and huge interface
(twisted.internet.app is nasty; ask anyone who has had to work on its
internals) which makes it even crummier and huger.
Huger: it inflates the interface by one more potentially redundant
class, so that we have that many more places to insert deprecation
warnings when we refactor the whole mess into something usable.
> + # Warning: On failure, service stops are not
> + # chained. However, they will stop in the proper order.
"utility" patches like this will invariably fail to take edge cases
into account well. I wouldn't say it's immediately obvious how
edge-cases *should* be taken into account, personally, but I would
guess that half-changing the semantics of the ordering in case of
failure is not the correct thing to do.
My concern is that some ill-thought-out parts of Twisted (twisted.cred,
twisted.internet.app) will become calcified behind a wide and fragile
interface that prevents any hope for refactoring. So far, development
on these kinds of problem areas has been fairly dynamic, because they
have been kept small and simple. However, the inevitable weight of
history is already slowing down more improvement. I would like to not
increase that weight any more than necessary.
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.1 (Darwin)
-----END PGP SIGNATURE-----
More information about the Twisted-Python