[Twisted-Python] Closing Jabber connection
I try to launch several jabber connections (BTW I use twisted 1.3). When the login is successful there's no problem, but whe the password is wrong I wanna to disconnect, I call connector.disconnect() but the event client.BasicAuthenticator.AUTH_FAILED_EVENT keep calling again and again. How I should close the connection so that event don't be called anymore? from twisted.protocols import jabber, xmlstream from twisted.protocols.jabber import client, jid from twisted.internet import reactor, defer class Connection: def __init__(self, who, myjid): self.jid = jid.JID(myjid) self.who = who def connect(self, passwd, port=5222): self.factory = client.basicClientFactory(self.jid, passwd) self.factory.addBootstrap(xmlstream.STREAM_AUTHD_EVENT, self.onAuthSuccess) self.factory.addBootstrap(client.BasicAuthenticator.AUTH_FAILED_EVENT, self.onAuthFailed) self.connector = reactor.connectTCP(self.jid.host, port, self.factory) def onAuthSuccess(self, stream): print "%s: Successful connection" % (self.who) self.stream = stream def onAuthFailed(self, stream): print "%s: Failed connection" % (self.who) self.connector.disconnect() c1 = Connection('1', 'client1@localhost/res1') c2 = Connection('2', 'client2@localhost/res1') c1.connect('client1') c2.connect('client22') reactor.run() The output is ('2' has wrong password) 1: Successful connection 2: Failed connection 2: Failed connection 2: Failed connection 2: Failed connection .... 2: Failed connection
On Mon, May 02, 2005 at 11:43:05AM -0300, Carolina Ardohain wrote:
Calling connector.disconnect() will only close the current connection. Since the factory returned by client.basicClientFactory is derived from twisted.internet.protocol.ReconnectingClientFactory, it will happily retry connecting unless you tell it not to. Solution: in onAuthFailed(), call self.factory.stopTrying(). By the way, as maintainer of the Jabber stuff in Twisted I can say that there a fair number of issues in the twisted 1.3 implementation. All of them have all been resolved in 2.0, and I strongly recommend you to migrate your work to this. -- Groetjes, ralphm
On Tue, May 03, 2005 at 01:14:43PM +0200, Tim Terlegård wrote:
Well, my first goal was to make sure the existing stuff works correctly. An example is having a good stringprep implementation for JIDs. This is mostly done now. The currently available code is usable to base any application on, but everything deals in domish Element objects. There are no higher level abstractions, yet, but some developers like it that way. There is no real plan on how to proceed, also because I have no idea of what is desired. So, any suggestions are welcome. Also, I am a bit curious about what the Jabber support in Twisted is currently used for. My current development efforts revolve around Idavoll (a generic publish subscribe component following JEP-0060) and Mimír (a Jabber enabled news service). -- Groetjes, ralphm
On 5/3/05, Ralph Meijer <twisted@ralphm.ik.nu> wrote:
I use it for various small projects, mostly bots and components. I also use it for punjab ( http://punjab.sf.net ). I would like to see other JEPS (muc would be cool), maybe some server stuff, and an authenticator with sasl. I may make an attempt with some of this stuff. I will submit what I do to the list. Is that ok?
On Tue, May 03, 2005 at 08:49:17AM -0400, Christopher Zorn wrote:
I think it would be good to clarify the overall objective. Lots of folks are interested in building a full reference implementation of the XMPP RFCs and various JEPs (probably those which have reached Draft in the JSF's standards process) in Python, but that seems like a major server effort rather than something which would necessarily go into Twisted. But perhaps I'm wrong about that. ;-) Peter
Peter Saint-Andre wrote:
Twisted _is_ a major server effort. What did you think it was? :) Seriously though, I would like to see more stuff like this go into Twisted if possible. The more functionality is built into the core, the more consistent that functionality will become over time, and the more different kinds of applications can access it.
On Tue, May 03, 2005 at 03:07:20PM -0400, Glyph Lefkowitz wrote:
Well, perhaps I've always misunderstood what Twisted is all about. From my perspective it's always seemed like an interconnected set of libraries, not a dedicated HTTP serverr or XMPP server or IRC server or whatever. (Yes, I know it does all of those and more.) So I thought that we'd build Jabber/XMPP support into some core level and then someone would come along and build a full-fledged Jabber server on top of that in a separate effort. Now it seems that Twisted Words is an effort to build a generic chat server of some kind, but I've not seen a roadmap for that, and it's not clear to me what it means to build a generic chat server. I know what it means to build a Jabber/XMPP server, and what it means to build an IRC server. But as far as I know there is no such thing as the "generic chat" protocol. :-) So will Words implement, say, the IRC RFCs and the XMPP RFCs and various XMPP extensions (defined in JEPs published by the JSF) and also SIP and SIMPLE and some less-open chat protocols such as Oscar, MSN, etc.? If so, how is all that stuff supposed to work together? Just curious. ;-) As I said, I know of several folks in the Jabber community who are quite interested in building a reference XMPP/Jabber server in Python, and I'm wondering if Words is the place to point them. Thanks! Peter
On Tue, May 03, 2005 at 03:17:34PM -0500, Peter Saint-Andre wrote:
Besides that, one could argue that XMPP/Jabber doesn't belong in Words alltogether because IM is just one possible use of XMPP/Jabber. -- Groetjes, ralphm
Ralph Meijer wrote:
One could argue that, but one would also be wrong :) Any protocol can be repurposed. Just look at some of the ridiculous things being done with HTTP that are not at all related to the dubious heading of "hypertext", which is what "web" originally meant. Or, consider how many proprietary ad-hoc systems use IRC as a message transport or router. Nevertheless, we classify these protocols according to their original intentions; IRC is not going into Twisted.ORB any time soon. Twisted Words is the place in Twisted for soft-real-time messaging protocols with human endpoints. They don't have to be transporting plain text, and they don't have to be using TCP (or even IP!). The ultimate goal is to provide a hub where messages can arrive over one protocol and be sent out over another. That's why the client and server halves of the protocols are in the same place, although previous projects (gaim, jabber, ircd) have separated these domains with a brick wall. A primary function of a Words server would be to act as a client to some other server so that it can provide a more civilized (say, Jabber, or Q2Q-Chat) interface to a legacy IRC or OSCAR server. This usually involves pretending to be at least one client. This may even include a co-dependency with Twisted Web for, for example, routing XMLRPC requests over Jabber into regular HTTP XMLRPC requests. However, initially it would be good to just have a multi-protocol messaging abstraction available which would allow for that sort of application. I wish I had more time to work on a roadmap but pretty much 150% of my time is spoken for right now. I am probably stealing time from somebody just writing this email! I hope that it has been useful.
I'm working on an application that would probably benefit from this abstraction. An example case from this app is receiving an SMS, via the aggregators gateway (clickatell) over http, then forwarding it to another "user" via Jabber. Doing this has had me banging on the jabber Twisted.Words from the 2.0 release quite a bit. Not sure if this adds to the conversation but I wanted to say "ooh, I'd like some of that please" re Glyphs comments. Robin Glyph Lefkowitz wrote:
On Wednesday 04 May 2005 09:30, Glyph Lefkowitz wrote:
*cough* SIMPLE *cough* t.p.sip doesn't go into twisted.words, either. -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
On May 3, 2005, at 11:10 PM, Anthony Baxter wrote:
Boy am I sorry I looked up SIMPLE. And here I thought SOAP was funny for calling itself simple...at least its *name* isn't SIMPLE. What is it with these protocols calling themselves "simple"... James
On Wednesday 04 May 2005 13:47, James Y Knight wrote:
SIMPLE is seriously seriously nasty. A worse impedance mismatch I've not seen in a long time. -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
Anthony Baxter wrote:
On Wednesday 04 May 2005 09:30, Glyph Lefkowitz wrote:
Any protocol can be repurposed.
*cough* SIMPLE *cough*
... OK, so some protocols are repurposed and some have their purpose surgically removed ...
t.p.sip doesn't go into twisted.words, either.
It doesn't? Why not? "Chat" doesn't have to mean "text", does it? ;-) Seriously though. NAT traversal code would be welcome in words. Maybe there's a common layer it depends upon? If it made sense to put SIMPLE anywhere in Twisted, it would be in twisted.words.
On Wednesday 04 May 2005 15:28, Glyph Lefkowitz wrote:
NAT traversal code (STUN, UPnP) would belong in something like twisted.internet, or maybe twisted.nat, or twisted.whichBitOfEnd2EndDidYouNotUnderstand It's useful for far more than just chat. -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
On Tue, May 03, 2005 at 07:30:19PM -0400, Glyph Lefkowitz wrote:
I can see your point and understand that people thinking of Jabber believe it must be in Words, but my initial remark on it not belonging there has more to do with that most of the current code doesn't belong where it is now. Yes, Jabber was originally designed for chat. I'd like to give a little bit of background to let you see where I'm coming from, and then giving my view about how the current organisation is not ideal. I hope you'll forgive me for the length of it. Since Jabber came to live back in 1999, much has changed. The base protocols have been revised and transformed into 2 RFCs: XMPP Core defines all basics about setting up an XML Stream using the default binding to TCP, channel encryption using TLS, authentication using SASL, the binding of a so-called 'resource' to a stream, the basic semantics of XML Stanzas (<message/>, <iq/> and <presence/> in whatever is the default namespace of the stream), a number of stream and stanza error conditions and finally the stringprep profiles for Jabber IDs. XMPP IM defines the core features for implementing Instant Messaging and Presence applications. This is where the server-to-server namespace and client-to-server namespace are defined for what is traditionally known as Jabber, all on top of XMPP Core. It defines what the XML Stanzas in these namespaces mean exactly and how they should be handled by servers and clients, what rosters (buddy lists) are and how entities can block selected communications. Then, the Jabber Software Foundation (JSF) defines a set of Jabber Enhancement Proposals. This set of documents, that started long before the IETF XMPP Workgroup was formed, defines additional protocols and best-practices on top of Jabber. Some assume XMPP IM as an environment, some only require XMPP Core. Examples range from multi-user-chat, sending XHTML messages and doing file transfers (all IM) to more general protocol additions like service discovery, publish-subscribe and a HTTP binding for XML Streams (as opposed to TCP). In Twisted, the current implementation of what is called Jabber is split between twisted.xish.xmlstream and twisted.words.protocols.jabber. In xmlstream, the basic concept of an XML stream is covered, and hooks for doing any kind of stream authentication. Everything else is in the jabber module. The jabber module only supports the legacy authentication method (not XMPP!) for setting up client-to-server connections (client side only), and there is no support for TLS, SASL or even error conditions. Recently I did implement XMPP stringprep profiles, though. The client module also has a raw implementation of abstracting the <iq/> stanza, by allowing you to wait for the response to a query. Higher level support for the other two stanzas, roster handling or blocking communication is not there. There is also a framework for building server-side components, but that is defined in a JEP, not by XMPP. My feeling is that the current implementation needs a lot of work, and I'd like to split that between implementing XMPP Core and XMPP IM. I could agree that the latter would belong in Words, but the former doesn't and that means that most of what is currently in Words needs to go to somewhere else. Maybe that somewhere-else is xish, but I didn't really like the moving xmlstream there, either. Maybe it'd be good to have a new twisted subproject XMPP that implements XMPP Core, and moving xmlstream there. There is no support for server-to-server connections and the server side of client-to-server and server component connections, yet. Having that, would be really great, though. While writing this, I decided I'd like to work on all this and help is of course appreciated. Thanks for your patience, -- Groetjes, ralphm
On 5/4/05, Ralph Meijer <twisted@ralphm.ik.nu> wrote:
In a puritanical "Each layer of abstraction should get its own subproject" view, you're right, but I think that we shouldn't add undue complexity to the project and confusion for people trying to understand Twisted by adding more projects when they're unnecessary. Therefore, I suggest keeping all of this stuff in twisted.words until it'd actually be useful to users (developers) to split off. i.e., when people start wanting to make apps based on XMPP that don't use any chat stuff. Anyway, good luck with the project, and thanks for your work on it so far. -- Twisted | Christopher Armstrong: International Man of Twistery Radix | -- http://radix.twistedmatrix.com | Release Manager, Twisted Project \\\V/// | -- http://twistedmatrix.com |o O| | Founding Member, Hobart Hacking Society w----v----w-+ -- http://hackingsociety.org/chapters/hash
I think it depends on the goals of this implementation. If this is a serious effort and we'd like this to be the "official" implementation of jabber in python, then I think XMPP Core and XMPP IM deserves to be seperate projects. Jabber with all JEPs would mean quite some code. If this only will be a minimal chat implementation, then I think words would suffice. Tim
Let me reply to the last thing you said first: Ralph Meijer wrote:
While writing this, I decided I'd like to work on all this and help is of course appreciated.
Awesome. I hope that my feelings about packaging and distribution don't discourage you! Words badly needs a dedicated maintainer and Jabber would be a great place to start, and probably not a bad model to structure the whole messaging system around.
On Tue, May 03, 2005 at 07:30:19PM -0400, Glyph Lefkowitz wrote:
Ralph Meijer wrote:
On Tue, May 03, 2005 at 03:17:34PM -0500, Peter Saint-Andre wrote:
Besides that, one could argue that XMPP/Jabber doesn't belong in Words alltogether because IM is just one possible use of XMPP/Jabber.
One could argue that, but one would also be wrong :)
Any protocol can be repurposed.
I still don't understand why you think Jabber can be a chat project that grows beyond that scope but you don't think that Words can be a chat project that grows beyond that scope :).
XMPP Core defines (...)
XMPP IM defines (...)
Then, the Jabber Software Foundation (JSF) defines a set of Jabber Enhancement Proposals. (...)
Okay... I did know most of that ;)
This is the core problem, I think. At this point, twisted.xish is simply support for the Jabber module in twisted.words, with no real legitimate life of its own. I believe it should be moved into twisted.words as a (admittedly largeish) protocol support module rather than having a separate installer and a separate project page. Factoring of XMPP IM/XMPP Core within Words would be a good idea, but this should not affect installation and deployment concerns, because there is no reason to use them separately right now. We should separate the project back out if people start clamoring for a separate distributable, but I seriously doubt this will be the case.
Obviously the implementation needs to be brought into line with more recent versions of all these specifications. No argument there :).
Again. I disagree. You spent a lot of text above talking about a lot of things which were allegedly supposed to back up this point, but I don't see how they're related. Jabber is a chat protocol which has been expanded to a wider array of application domains, Words is a project to enable expanding chat protocols to handle a wider array of application domains. We have already made a sort of policy decision at a global level to bundle protocol logic in the application modules that it supports, i.e. twisted FTP protocol and HTTP protocol support belong in twisted.web, NOT in some common protocol-abstractions-only package. You might have an application which uses only the XMPP core parts of Words, but those sorts of applications are, in my experience, *extremely* rare, and should not distort the marketing of the project and normal experience of people downloading the code or hacking on it for the first time. Internal factoring is a separate question to packaging; if I view them in the light of internal factoring, your ideas all seem good. If I view them as packaging, they're all bad.
To reiterate, what is currently in Words needs to stay in Words, and things which support it that are not otherwise used needs to move there next to them. Twisted subprojects are organized around some set of application functionality that can be provided by the core. Twisted Words' provided application is a multiprotocol chat server and client, with chatterbot support. Like all Twisted projects, the code can be used at any level, whether it's to load into the provided application as a plug-in or to develop a new application on top of only a subset of a package. There is a cultural feeling in the Jabber community, I think, that Jabber is somehow unique and should be segregated and separated from all the other "legacy" protocols that are "just chat". All chat protocols support a range of functionality. IRC really is used as a message routing platform, in some cases in actual serious applications. As far as I know OSCAR is used both for chat and for some back-end message delivery at AOL. Even just on the chat client, it has a range of extensions which is pretty impressive. MSN's protocol is used for more than just messenger. All these protocols have a message format and a chat layer and an extension layer, and equal support for all of them should not be precluded. Jabber is not a beautiful and unique snowflake. It is the all-singing all dancing chat of the world ;) That said, Jabber does have advantages over these protocols in many ways. As I said above, it would not bother me to see the bulk of the Twisted Words architected around it. Still, it would be a mistake to break the project up into multiple pieces first. A key hint that this is a bad place to break the project is that the design for both halves is going to be done by one person as one effort, rather than building an XMPP core application and then waiting a few months to a year and then building an XMPP IM extension to that - the useful bits are up in XMPP IM, and XMPP core is just support code for that. It certainly may be useful support code for a wide range of other applications but it does not stand on its own yet.
On Wed, May 04, 2005 at 10:53:46AM -0400, Glyph Lefkowitz wrote:
Thanks! I realize this is probably a bigger effort than I can imagine now. I'm not wedded to any packaging structure, really. The most important thing right now is getting the code out there. Most of my longish message was thinking out loud and certainly helped me to get an idea of a restructuring of the code. Also, I can follow the reasoning of keeping it inside Words at the moment. We'll see where that leaves Xish, but let's not get ahead of myself. I must admit that I haven't really looked into the rest of Words, but if I understand you correctly the development there is stagnant. That's a shame, but we can see that in the Jabber community as well: there are very few people that bother to work on Gateways to other IM networks. The bright side to that story is that from what I can see, the development that /is/ there is implemented using Twisted :-) Let's get coding. -- Groetjes, ralphm
Ralph Meijer wrote:
On Wed, May 04, 2005 at 10:53:46AM -0400, Glyph Lefkowitz wrote:
I'd estimate ten years, as with any such project :) - http://www.norvig.com/21-days.html
Double-awesome!
I must admit that I haven't really looked into the rest of Words, but if I understand you correctly the development there is stagnant.
Yes. I was the original developer, and as far as I know very little has happened since I was working on it. The chat client part of words still uses 1.0-era deprecated APIs, and has a gtk1 user interface! Much of the code's design is also horrible, as it was written more as a proof of concept. Still, I strongly believe that words is where a good bit of Twisted's potential lies. A lot of what's being done with Twisted now could theoretically be done with apache, but once chat protocols start getting into the mix there are very few things that can compete.
On Mon, May 02, 2005 at 11:43:05AM -0300, Carolina Ardohain wrote:
Calling connector.disconnect() will only close the current connection. Since the factory returned by client.basicClientFactory is derived from twisted.internet.protocol.ReconnectingClientFactory, it will happily retry connecting unless you tell it not to. Solution: in onAuthFailed(), call self.factory.stopTrying(). By the way, as maintainer of the Jabber stuff in Twisted I can say that there a fair number of issues in the twisted 1.3 implementation. All of them have all been resolved in 2.0, and I strongly recommend you to migrate your work to this. -- Groetjes, ralphm
On Tue, May 03, 2005 at 01:14:43PM +0200, Tim Terlegård wrote:
Well, my first goal was to make sure the existing stuff works correctly. An example is having a good stringprep implementation for JIDs. This is mostly done now. The currently available code is usable to base any application on, but everything deals in domish Element objects. There are no higher level abstractions, yet, but some developers like it that way. There is no real plan on how to proceed, also because I have no idea of what is desired. So, any suggestions are welcome. Also, I am a bit curious about what the Jabber support in Twisted is currently used for. My current development efforts revolve around Idavoll (a generic publish subscribe component following JEP-0060) and Mimír (a Jabber enabled news service). -- Groetjes, ralphm
On 5/3/05, Ralph Meijer <twisted@ralphm.ik.nu> wrote:
I use it for various small projects, mostly bots and components. I also use it for punjab ( http://punjab.sf.net ). I would like to see other JEPS (muc would be cool), maybe some server stuff, and an authenticator with sasl. I may make an attempt with some of this stuff. I will submit what I do to the list. Is that ok?
On Tue, May 03, 2005 at 08:49:17AM -0400, Christopher Zorn wrote:
I think it would be good to clarify the overall objective. Lots of folks are interested in building a full reference implementation of the XMPP RFCs and various JEPs (probably those which have reached Draft in the JSF's standards process) in Python, but that seems like a major server effort rather than something which would necessarily go into Twisted. But perhaps I'm wrong about that. ;-) Peter
Peter Saint-Andre wrote:
Twisted _is_ a major server effort. What did you think it was? :) Seriously though, I would like to see more stuff like this go into Twisted if possible. The more functionality is built into the core, the more consistent that functionality will become over time, and the more different kinds of applications can access it.
On Tue, May 03, 2005 at 03:07:20PM -0400, Glyph Lefkowitz wrote:
Well, perhaps I've always misunderstood what Twisted is all about. From my perspective it's always seemed like an interconnected set of libraries, not a dedicated HTTP serverr or XMPP server or IRC server or whatever. (Yes, I know it does all of those and more.) So I thought that we'd build Jabber/XMPP support into some core level and then someone would come along and build a full-fledged Jabber server on top of that in a separate effort. Now it seems that Twisted Words is an effort to build a generic chat server of some kind, but I've not seen a roadmap for that, and it's not clear to me what it means to build a generic chat server. I know what it means to build a Jabber/XMPP server, and what it means to build an IRC server. But as far as I know there is no such thing as the "generic chat" protocol. :-) So will Words implement, say, the IRC RFCs and the XMPP RFCs and various XMPP extensions (defined in JEPs published by the JSF) and also SIP and SIMPLE and some less-open chat protocols such as Oscar, MSN, etc.? If so, how is all that stuff supposed to work together? Just curious. ;-) As I said, I know of several folks in the Jabber community who are quite interested in building a reference XMPP/Jabber server in Python, and I'm wondering if Words is the place to point them. Thanks! Peter
On Tue, May 03, 2005 at 03:17:34PM -0500, Peter Saint-Andre wrote:
Besides that, one could argue that XMPP/Jabber doesn't belong in Words alltogether because IM is just one possible use of XMPP/Jabber. -- Groetjes, ralphm
Ralph Meijer wrote:
One could argue that, but one would also be wrong :) Any protocol can be repurposed. Just look at some of the ridiculous things being done with HTTP that are not at all related to the dubious heading of "hypertext", which is what "web" originally meant. Or, consider how many proprietary ad-hoc systems use IRC as a message transport or router. Nevertheless, we classify these protocols according to their original intentions; IRC is not going into Twisted.ORB any time soon. Twisted Words is the place in Twisted for soft-real-time messaging protocols with human endpoints. They don't have to be transporting plain text, and they don't have to be using TCP (or even IP!). The ultimate goal is to provide a hub where messages can arrive over one protocol and be sent out over another. That's why the client and server halves of the protocols are in the same place, although previous projects (gaim, jabber, ircd) have separated these domains with a brick wall. A primary function of a Words server would be to act as a client to some other server so that it can provide a more civilized (say, Jabber, or Q2Q-Chat) interface to a legacy IRC or OSCAR server. This usually involves pretending to be at least one client. This may even include a co-dependency with Twisted Web for, for example, routing XMLRPC requests over Jabber into regular HTTP XMLRPC requests. However, initially it would be good to just have a multi-protocol messaging abstraction available which would allow for that sort of application. I wish I had more time to work on a roadmap but pretty much 150% of my time is spoken for right now. I am probably stealing time from somebody just writing this email! I hope that it has been useful.
I'm working on an application that would probably benefit from this abstraction. An example case from this app is receiving an SMS, via the aggregators gateway (clickatell) over http, then forwarding it to another "user" via Jabber. Doing this has had me banging on the jabber Twisted.Words from the 2.0 release quite a bit. Not sure if this adds to the conversation but I wanted to say "ooh, I'd like some of that please" re Glyphs comments. Robin Glyph Lefkowitz wrote:
On Wednesday 04 May 2005 09:30, Glyph Lefkowitz wrote:
*cough* SIMPLE *cough* t.p.sip doesn't go into twisted.words, either. -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
On May 3, 2005, at 11:10 PM, Anthony Baxter wrote:
Boy am I sorry I looked up SIMPLE. And here I thought SOAP was funny for calling itself simple...at least its *name* isn't SIMPLE. What is it with these protocols calling themselves "simple"... James
On Wednesday 04 May 2005 13:47, James Y Knight wrote:
SIMPLE is seriously seriously nasty. A worse impedance mismatch I've not seen in a long time. -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
Anthony Baxter wrote:
On Wednesday 04 May 2005 09:30, Glyph Lefkowitz wrote:
Any protocol can be repurposed.
*cough* SIMPLE *cough*
... OK, so some protocols are repurposed and some have their purpose surgically removed ...
t.p.sip doesn't go into twisted.words, either.
It doesn't? Why not? "Chat" doesn't have to mean "text", does it? ;-) Seriously though. NAT traversal code would be welcome in words. Maybe there's a common layer it depends upon? If it made sense to put SIMPLE anywhere in Twisted, it would be in twisted.words.
On Wednesday 04 May 2005 15:28, Glyph Lefkowitz wrote:
NAT traversal code (STUN, UPnP) would belong in something like twisted.internet, or maybe twisted.nat, or twisted.whichBitOfEnd2EndDidYouNotUnderstand It's useful for far more than just chat. -- Anthony Baxter <anthony@interlink.com.au> It's never too late to have a happy childhood.
On Tue, May 03, 2005 at 07:30:19PM -0400, Glyph Lefkowitz wrote:
I can see your point and understand that people thinking of Jabber believe it must be in Words, but my initial remark on it not belonging there has more to do with that most of the current code doesn't belong where it is now. Yes, Jabber was originally designed for chat. I'd like to give a little bit of background to let you see where I'm coming from, and then giving my view about how the current organisation is not ideal. I hope you'll forgive me for the length of it. Since Jabber came to live back in 1999, much has changed. The base protocols have been revised and transformed into 2 RFCs: XMPP Core defines all basics about setting up an XML Stream using the default binding to TCP, channel encryption using TLS, authentication using SASL, the binding of a so-called 'resource' to a stream, the basic semantics of XML Stanzas (<message/>, <iq/> and <presence/> in whatever is the default namespace of the stream), a number of stream and stanza error conditions and finally the stringprep profiles for Jabber IDs. XMPP IM defines the core features for implementing Instant Messaging and Presence applications. This is where the server-to-server namespace and client-to-server namespace are defined for what is traditionally known as Jabber, all on top of XMPP Core. It defines what the XML Stanzas in these namespaces mean exactly and how they should be handled by servers and clients, what rosters (buddy lists) are and how entities can block selected communications. Then, the Jabber Software Foundation (JSF) defines a set of Jabber Enhancement Proposals. This set of documents, that started long before the IETF XMPP Workgroup was formed, defines additional protocols and best-practices on top of Jabber. Some assume XMPP IM as an environment, some only require XMPP Core. Examples range from multi-user-chat, sending XHTML messages and doing file transfers (all IM) to more general protocol additions like service discovery, publish-subscribe and a HTTP binding for XML Streams (as opposed to TCP). In Twisted, the current implementation of what is called Jabber is split between twisted.xish.xmlstream and twisted.words.protocols.jabber. In xmlstream, the basic concept of an XML stream is covered, and hooks for doing any kind of stream authentication. Everything else is in the jabber module. The jabber module only supports the legacy authentication method (not XMPP!) for setting up client-to-server connections (client side only), and there is no support for TLS, SASL or even error conditions. Recently I did implement XMPP stringprep profiles, though. The client module also has a raw implementation of abstracting the <iq/> stanza, by allowing you to wait for the response to a query. Higher level support for the other two stanzas, roster handling or blocking communication is not there. There is also a framework for building server-side components, but that is defined in a JEP, not by XMPP. My feeling is that the current implementation needs a lot of work, and I'd like to split that between implementing XMPP Core and XMPP IM. I could agree that the latter would belong in Words, but the former doesn't and that means that most of what is currently in Words needs to go to somewhere else. Maybe that somewhere-else is xish, but I didn't really like the moving xmlstream there, either. Maybe it'd be good to have a new twisted subproject XMPP that implements XMPP Core, and moving xmlstream there. There is no support for server-to-server connections and the server side of client-to-server and server component connections, yet. Having that, would be really great, though. While writing this, I decided I'd like to work on all this and help is of course appreciated. Thanks for your patience, -- Groetjes, ralphm
On 5/4/05, Ralph Meijer <twisted@ralphm.ik.nu> wrote:
In a puritanical "Each layer of abstraction should get its own subproject" view, you're right, but I think that we shouldn't add undue complexity to the project and confusion for people trying to understand Twisted by adding more projects when they're unnecessary. Therefore, I suggest keeping all of this stuff in twisted.words until it'd actually be useful to users (developers) to split off. i.e., when people start wanting to make apps based on XMPP that don't use any chat stuff. Anyway, good luck with the project, and thanks for your work on it so far. -- Twisted | Christopher Armstrong: International Man of Twistery Radix | -- http://radix.twistedmatrix.com | Release Manager, Twisted Project \\\V/// | -- http://twistedmatrix.com |o O| | Founding Member, Hobart Hacking Society w----v----w-+ -- http://hackingsociety.org/chapters/hash
I think it depends on the goals of this implementation. If this is a serious effort and we'd like this to be the "official" implementation of jabber in python, then I think XMPP Core and XMPP IM deserves to be seperate projects. Jabber with all JEPs would mean quite some code. If this only will be a minimal chat implementation, then I think words would suffice. Tim
Let me reply to the last thing you said first: Ralph Meijer wrote:
While writing this, I decided I'd like to work on all this and help is of course appreciated.
Awesome. I hope that my feelings about packaging and distribution don't discourage you! Words badly needs a dedicated maintainer and Jabber would be a great place to start, and probably not a bad model to structure the whole messaging system around.
On Tue, May 03, 2005 at 07:30:19PM -0400, Glyph Lefkowitz wrote:
Ralph Meijer wrote:
On Tue, May 03, 2005 at 03:17:34PM -0500, Peter Saint-Andre wrote:
Besides that, one could argue that XMPP/Jabber doesn't belong in Words alltogether because IM is just one possible use of XMPP/Jabber.
One could argue that, but one would also be wrong :)
Any protocol can be repurposed.
I still don't understand why you think Jabber can be a chat project that grows beyond that scope but you don't think that Words can be a chat project that grows beyond that scope :).
XMPP Core defines (...)
XMPP IM defines (...)
Then, the Jabber Software Foundation (JSF) defines a set of Jabber Enhancement Proposals. (...)
Okay... I did know most of that ;)
This is the core problem, I think. At this point, twisted.xish is simply support for the Jabber module in twisted.words, with no real legitimate life of its own. I believe it should be moved into twisted.words as a (admittedly largeish) protocol support module rather than having a separate installer and a separate project page. Factoring of XMPP IM/XMPP Core within Words would be a good idea, but this should not affect installation and deployment concerns, because there is no reason to use them separately right now. We should separate the project back out if people start clamoring for a separate distributable, but I seriously doubt this will be the case.
Obviously the implementation needs to be brought into line with more recent versions of all these specifications. No argument there :).
Again. I disagree. You spent a lot of text above talking about a lot of things which were allegedly supposed to back up this point, but I don't see how they're related. Jabber is a chat protocol which has been expanded to a wider array of application domains, Words is a project to enable expanding chat protocols to handle a wider array of application domains. We have already made a sort of policy decision at a global level to bundle protocol logic in the application modules that it supports, i.e. twisted FTP protocol and HTTP protocol support belong in twisted.web, NOT in some common protocol-abstractions-only package. You might have an application which uses only the XMPP core parts of Words, but those sorts of applications are, in my experience, *extremely* rare, and should not distort the marketing of the project and normal experience of people downloading the code or hacking on it for the first time. Internal factoring is a separate question to packaging; if I view them in the light of internal factoring, your ideas all seem good. If I view them as packaging, they're all bad.
To reiterate, what is currently in Words needs to stay in Words, and things which support it that are not otherwise used needs to move there next to them. Twisted subprojects are organized around some set of application functionality that can be provided by the core. Twisted Words' provided application is a multiprotocol chat server and client, with chatterbot support. Like all Twisted projects, the code can be used at any level, whether it's to load into the provided application as a plug-in or to develop a new application on top of only a subset of a package. There is a cultural feeling in the Jabber community, I think, that Jabber is somehow unique and should be segregated and separated from all the other "legacy" protocols that are "just chat". All chat protocols support a range of functionality. IRC really is used as a message routing platform, in some cases in actual serious applications. As far as I know OSCAR is used both for chat and for some back-end message delivery at AOL. Even just on the chat client, it has a range of extensions which is pretty impressive. MSN's protocol is used for more than just messenger. All these protocols have a message format and a chat layer and an extension layer, and equal support for all of them should not be precluded. Jabber is not a beautiful and unique snowflake. It is the all-singing all dancing chat of the world ;) That said, Jabber does have advantages over these protocols in many ways. As I said above, it would not bother me to see the bulk of the Twisted Words architected around it. Still, it would be a mistake to break the project up into multiple pieces first. A key hint that this is a bad place to break the project is that the design for both halves is going to be done by one person as one effort, rather than building an XMPP core application and then waiting a few months to a year and then building an XMPP IM extension to that - the useful bits are up in XMPP IM, and XMPP core is just support code for that. It certainly may be useful support code for a wide range of other applications but it does not stand on its own yet.
On Wed, May 04, 2005 at 10:53:46AM -0400, Glyph Lefkowitz wrote:
Thanks! I realize this is probably a bigger effort than I can imagine now. I'm not wedded to any packaging structure, really. The most important thing right now is getting the code out there. Most of my longish message was thinking out loud and certainly helped me to get an idea of a restructuring of the code. Also, I can follow the reasoning of keeping it inside Words at the moment. We'll see where that leaves Xish, but let's not get ahead of myself. I must admit that I haven't really looked into the rest of Words, but if I understand you correctly the development there is stagnant. That's a shame, but we can see that in the Jabber community as well: there are very few people that bother to work on Gateways to other IM networks. The bright side to that story is that from what I can see, the development that /is/ there is implemented using Twisted :-) Let's get coding. -- Groetjes, ralphm
Ralph Meijer wrote:
On Wed, May 04, 2005 at 10:53:46AM -0400, Glyph Lefkowitz wrote:
I'd estimate ten years, as with any such project :) - http://www.norvig.com/21-days.html
Double-awesome!
I must admit that I haven't really looked into the rest of Words, but if I understand you correctly the development there is stagnant.
Yes. I was the original developer, and as far as I know very little has happened since I was working on it. The chat client part of words still uses 1.0-era deprecated APIs, and has a gtk1 user interface! Much of the code's design is also horrible, as it was written more as a proof of concept. Still, I strongly believe that words is where a good bit of Twisted's potential lies. A lot of what's being done with Twisted now could theoretically be done with apache, but once chat protocols start getting into the mix there are very few things that can compete.
participants (11)
-
Anthony Baxter -
Carolina Ardohain -
Christopher Armstrong -
Christopher Zorn -
Glyph Lefkowitz -
Itamar Shtull-Trauring -
James Y Knight -
Peter Saint-Andre -
Ralph Meijer -
Robin Bryce -
Tim Terlegård