Norman Rasmussen a écrit : >> Our fixes are and will be free software, you’ll be able to take them back if >> you >> want. However, I have the intention to change quite a lot of things: revamp >> simplexmp, replace debug with standard logging, get rid of fake inheritance, >> etc. Are these ground-breaking changes suitable for incorporation in xmpppy? > > as far as I'm concerned: > - simplexml is ugly and should be thrown away. something like the > standard python xml.dom and xml.sax (maybe xml.dom.pulldom) would be > more than enough I don't think that removing simplexml would be a good thing. simplexml is simple (Captain Obvious agrees), and having a simple API to make Python objets from an XML stream (thanks to expat) and serialize them back (thanks to __str__) seems useful to me. I prefer cleaning simplexml than using DOM. I think we don’t need such a complicated interface to handle stanzas.
> - not sure what you mean about the fake inheritance - do you mean the > plugging? Yes, the plugin system and the horror[1] in client.py (CommonClient is derivated in Client and Component, but its contructor does different things according to the one call it (Client.__init__ or Component.__init__)). And other stuff like this one. [1] http://trac.last-exile.org/xmppony/browser/trunk/xmppony/client.py?rev=30#L119 > > Much of the code of xmpp.py was written by Alexey _before_ python had > support for all this stuff in it's internal libraries. I've had to > deal with being able to run the transports on Python 2.2. I think > Alexey did a fantastic job with what he had to work with when he wrote > the library. Unfortunately (as it happens to all of us), he was > unable to dedicate as much time as he would have wanted to maintaining > the library. > As I already said to steve-e, I thank him for his job and I don't blame him: he has his life. > Moving forwards I would like to see: > - true asynchronous code - Gajim team did this about a year ago. > They added non-blocking calls for almost everything that used to > block. Support for asyncore would be great, because this is another > python built-in library. I don't understand why people do not like threads :'( threading is a standard Python module too. > - cleaner separation of concerns - the Gajim team have started on > this. The client should not care if the server connection is TCP or > TLS or SSL or BOSH or Magic-transport-method-5. That sounds good. I want Magic-transport-method-5 \o/ > - the library should continue to support client and transport > connections. adhoc commands should get client-side (consumer) support > (currently only server-side (producer) is supported). Adhoc commands, pep, and other cool stuff are on my roadmap for v0.3. > - file transfer would be fantastic, would you support all 5 methods? > (si, ibb, oob, socks5, jingle) > For now, xmppony supports si, socks5 and ibb. With emacs-jabber, I can already send and receive files from a bot based on xmppony. Jingle support would be great, but I didn't plan to touch it now (except if someone sends me a patch). As I said in previous mail, for v0.2, I plan to revamp simplexml, replace debug with standard logging and get rid of fake inheritance. But I also take a look to rfcs and xeps. Because they evolved since the code was written. For example, I found 2 problems in omega's patch (which was written 4-5 years ago). I also plan to make some unit tests. The base must be cleanest possible before going further! -- Anaël Verrier xmpp:[email protected] GPG: 1024D/65B95D84 _______________________________________________ JDev mailing list Forum: http://www.jabberforum.org/forumdisplay.php?f=20 Info: http://mail.jabber.org/mailman/listinfo/jdev Unsubscribe: [email protected] _______________________________________________
