muc client support

[tofu]

MUC client protocol support is needed for creating generic xmpp clients that support multi-user chat.

[tofu]

source:branches/wokkel-muc-client-support-24

[tofu]

(In [69]) add basic errors and disco stuff, still need iq and message parts re #24

[tofu]

(In [70]) add room configuration, groupchat and some clean up, still needs documentation and a bit more stuff to add re #24

[tofu]

(In [72]) add leave room, register for a room and other things for re #24, still need admin and owner stuff, more tests and more docs

[tofu]

(In [111]) we now have basic support with nick change, also added some doc strings, still need more re #24

[tofu]

I believe I have the basics ready for review. By basics I support the basics defined in the XEP. I also support each part of the Use cases, Members, Moderators and Owners. I have some tests for each of these cases. I feel we should try and get what I have merged and then for additional features we will make separate tickets.

One ticket would eventually have an API similar to the regular chat API in twisted.words.

Please review.

[ralphm]

This is my first review of this code, mostly based on coding style, docstrings, interface consistency and tests. Please don't be discouraged by the strictness, but it is required if we want to move this to Twisted and has proved to make better code in the end. Let's figure out how we can address these points in several steps.

In general, I'd like Wokkel to adhere to the  Twisted Coding Standard which in turn depends on  Python's Style Guide. Futhermore, the expectations in terms of testing are mentioned in  Unit Tests in Twisted. More specific comments follow:

The protocol additions for Service Discovery should be done in #28, so that makes this branch depend on that. I have some thoughts about how that should be done, but we can solve that in some future iteration.

On IMUCClient:

• Every interface method must have docstrings that explain what it is for and what its parameters are, what they are for and what their type(s) may be. Also document what is returned by a method and the return type.
• Parameters, like other variables, must be in camelCase and have descriptive names. E.g. roomJID instead of room_jid. Also, to doesn't tell me much in itself, so maybe recipient or occupant would be better.
• Try to maintain a consistent interface. The join method has server and room arguments, whereas leave has room_jid. And then userJoinedRoom has room, which is a muc.Room instance.
• Don't use empty lists as default values for function/method arguments:

>>> def a(b=[]):
...   b.append(3)
...   print b
>>> a()
[3]
>>> a()
[3, 3]
>>> a()
[3, 3, 3]

In muc.py:

• The naming of classes here should use some additional context. Prefixing MUC would be nice.
• I am a bit mystified about sendDeferred being a public method in IRCClient. This looks similar to the IQ reply functionality in Words, and could some more generalization.

Well, that's enough for this round.

[kapilt]

any movement on getting this merged into trunk?

[kapilt]

i'd be happy to help clean it up, the review items look pretty minor.

[ralphm]

I've been working on this, but it is a bit stalled at the moment. My current work is here:  http://hg.ik.nu/ralphm/wokkel-muc-client-support-24-2. I hope to fix it up soon.