[jdev] xmppony 0.1 is released!

[Norman Rasmussen]

On Fri, Apr 10, 2009 at 9:47 PM, Anaël Verrier <elghinn at free.fr> wrote:
> 1) I have submited a patch[1] 11 months ago.
> But my patch was waiting without responses. It was not alone[2][3][4][5].

Unfortunately I haven't been looking at the bug tracker on sf.net, I
haven't had time to more than apply patches sent to the mailing list.

> 2) No clues the project was alive.

the xmpp.py mailing list has about 5 or so threads per month, of which
I read each and every message.  If this thread gets anymore detailed,
I think we should perhaps redirect it to that list so that we don't
overwhelm the jdev list with our plans to rule python-xmpp
development.

> 3) We didn’t announce anything before we had something to announce.
> I do not have as a practice to announce a project prematurely.

sounds good

> 4) Misfortunate timing.
> I have forked the 03/26/09 as you can see on the project timeline[8]. And
> released it today. When I have forked, Alexey had not improved yet with the
> code. Thus I had already made things before he is not put at it.
> Yes, when I make the release, that made already 4-5 days that there had been of
> the activity on the repository. But I only saw it when the release was done.

true, misfortunate timing, yes.

> 5) Grégoire Menuel proposed a patch[9] for the file transfer.
> But you refused it. And whatever is the reason, at the current hour we can not
> still make a file transfer with xmpppy.

wow, this was from before I started on xmpp.py.  Do you know that
there were no less than 3 requests for file transfer code in the last
6 months.  If I'd known I would have at least looked at the patch.

> 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
 - agree on the debugging
 - not sure what you mean about the fake inheritance - do you mean the
plugging?

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.

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.
 - 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.
 - 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).
 - file transfer would be fantastic, would you support all 5 methods?
(si, ibb, oob, socks5, jingle)

-- 
- Norman Rasmussen
 - Email: norman at rasmussen.co.za
 - Home page: http://norman.rasmussen.co.za/