[Twisted-Python] Bloat (was Re: [Twisted-commits] DependentMultiService - chained start/stop of services in a sensible order)

[Glyph Lefkowitz]

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

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 
> order

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 
apply.

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.

Crummier:

> +        # 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)

iD8DBQE+mgGcvVGR4uSOE2wRAiuSAKC4TvM4Xtqo3kR64/Z69ZxTh9rKpQCgmnJJ
rkXEyqUu1Rxs9DRjo1T9BS4=
=YYZ9
-----END PGP SIGNATURE-----