[Twisted-Python] Freevo 2.0, Kamaelia, pyevent, Eventnet/LGT: what's going on?

[Antoine Pitrou]

Hi,

Thanks for the answers...

> > - high-level features seem better avoided since documentation is often
> > very lacking and the API does not seem stable
> 
> Well... I have applications running on twisted for over an year without any
> breakage in API.

Oh, I have too. But only using the basic networking stuff, because I'm
not confident enough to touch the high-level things.

Parts of the Twisted API are marked as "API unstable". I don't think I
dreamed it, since I've read it in the doc ;)
Also I've seen several times some answers on this very list which were
of the sort "actually this module is not maintained anymore" (or
"experimental").

> Documentation is lacking sometimes, only for
> jabber AFAIK.

There is a whole lot of methods which are not documented at all. Also,
there is usually no comprehensive documentation for a specific
functionality. Not to mention the annoying interface system which means
the documentation for e.g. twisted.internet.reactor.ListenTCP is
actually to be found elsewhere in the class hierarchy...

> > - design choices are not documented at all (for example, why a custom
> > logging module instead of the Python-provided one?), so they often look
> > gratuitous
> 
> The python standard one do not seem so nice. In fact there are a number of
> projects to substitute it with something better. One is twisted.python.log
> another is py.log and there are others out there. Another example?

As I said the problem is that it's not documented anywhere. That doesn't
mean there isn't any reason, just that a normal developer cannot guess
by himself. When I see a library with lots of design decisions for which
I can't find any rationale, I'm legitimately suspicious (it could just
be the NIH syndrome which we all know very well - since we have all one
day fallen for it ;-)).

> PB is not proprietary... The protocol is documented (maybe it's the best
> documented thing in twisted) and source code is available.

It is proprietary in the sense that it is, AFAIK, implemented only by
Twisted.
Contrast this with e.g. XMLRPC which has lots of implementations. XMLRPC
is quite mediocre, but at least I know that mostly everyone can find an
implementation for his/her favourite programming language.
I won't ever use PB for something for which I want others to be able to
write clients easily (without forcing them to use Twisted). It's a
simple matter of simplifying interoperability. For some people/projects
it matters very much, for others it doesn't matter at all.

> The Factory keeps state for many protocols since the protocol is created and
> destroyed with the connection. Seems rather obvious for anybody having just
> read the basic finger tutorial.

There is a terminology problem, since I don't understand why something
named "Protocol" should be destroyed at every connection. Or it should
be, quite logically, renamed "Connection". Also this doesn't appear in
the API docs (again).

For me, a "protocol" is something like HTTP or SMTP. It is "eternal",
I'm not expecting it to be created/destroyed at every connection (that
would be like calling an int a float, or whatever).

There is no documentation on the magic that really happens when
something is triggered (for example when a TCP session is established).
Which methods are called, which objects are created, in which order,
etc. Unexplained magic is annoying in software development.

> If you don't want to learn anything of course. If instead you go beyond the
> surface and learn something for real then it may happen that you find it is
> istead a great problem solver for a lot of problems.

It's not that I don't want to learn. It's that the more you use
framework-specific constructs, and the higher level those constructs
are, the more your software project is stuck with this framework and
difficult to reuse/adapt/port/interoperate with. Of course, some
projects (especially proprietary or internal ones) are less sensitive to
this than others.

Again, that does not change the fact that I'm quite happy with the parts
of Twisted I do use. The simple notion of a Deferred (with its two
callbacks) for example, is brilliant.

Regards

Antoine.