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

[Valentino Volonghi aka Dialtone]

On Thu, Oct 20, 2005 at 05:51:20PM +0200, Antoine Pitrou wrote:
> - 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. And API compatibility is guaranteed between minor release,
and I'd say also major right now, since there is also a complete compatibility
layer for the old interfaces. Documentation is lacking sometimes, only for
jabber AFAIK. There are plenty of tests and examples. Also when you understand
twisted everything else comes just straight off.

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

> - the tendency to advocate proprietary protocols (like PB) without
> warning the user should be mitigated

PB is not proprietary... The protocol is documented (maybe it's the best
documented thing in twisted) and source code is available. Then why should you
warn somebody for using a very good thing?

> - the architecture is sometimes bizarre or badly described (the
> credential stuff looks like Chinese to me); for example, why is there a
> distinction between "*Protocol" and "*Factory" types?

You are being unfair here. I'm sorry to sound harsh but if you don't
understand something it doesn't mean that it's bizarre or hairy.

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.

The credential stuff couldn't be easier than that.
It's pluggable, which means that it can be put in front of anything, but there
must be a way, for this anything, to retrieve credentials for the user that is
currently requiring the login, which means that it is made of a protocol side
and a twisted.cred side.

In the case of Nevow the protocol side is guard.py and then there is cred.
The aim of guard is to retrieve the arguments username and password from the
request and pass them to portal.login(). Portal login has a set of checkers
and a realm.

What happens is:
the portal calls requestAvatarId on the checker passing the credentials to it.
If the credentials are checked it will return an avatarId, otherwise it will
raise an UnauthorizedLogin exception.
after the portal as received the result of the requestAvatarId it then calls
requestAvatar on the realm passing the avatarId to it and the interface
associated with where the login request came from (web, pb, ftp, whatever)
[also supplied by guard].
then the result of requestAvatar is displayed to the user.

I wouldn't know how to do this in an easier and simpler way, yet maintaining
the same code reusability.

> I often recommend the use of Twisted for standard network functions. But
> I stay away of the more sophisticated stuff (including twistd, PB,
> Nevow, etc.). Grouping all this stuff together with the basic, trusted,
> dependable network classes may yield a perception of twisted as
> bloatware.

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.

-- 
Valentino Volonghi aka Dialtone
Now Running MacOSX 10.4
Blog: http://vvolonghi.blogspot.com
http://weever.berlios.de
-------------- next part --------------
A non-text attachment was scrubbed...
Name: not available
Type: application/pgp-signature
Size: 186 bytes
Desc: not available
URL: </pipermail/twisted-python/attachments/20051020/48191447/attachment.sig>