[crosspost from xmpp.py list]
I have put together a first pass patch [1] at getting xmpp.py to speak
the jabberd 2.0 Component Protocol [2].
I do not like the way I have hooked the dispatch event. I'm less
horrified, by how I've mangled the send event. That being said, the
patch *does* work
2005/8/25, Stephen Marquard [EMAIL PROTECTED]:
Is anyone interested in this becoming a real JEP rather than j2 internal
documentation, i.e. would it be worth the effort to submit it to the JEP
process?
The solution for getting a component to automatically work under more
than one hostname is
I've been having at trying to get the yahoo-transport from the xmpp.py
project to work with this JEP., here's my problem
Is bind in the root namespace?
for most componenents the default namespace is set to
jabber:component:accept, so this makes any bind calls occur in the
Hey Stephen,
When Matt and I read jabberd2's component JEP we liked many things. :) I
think that in general the JEP is fine but we may need to discuss sections
3.5 and 3.6 (and maybe 3.7). We can start a new thread to discuss this JEP
and also discuss how to improve the existing JEP. One thing
Norman Rasmussen wrote:
I've been having at trying to get the yahoo-transport from the xmpp.py
project to work with this JEP., here's my problem
Is bind in the root namespace?
for most componenents the default namespace is set to
jabber:component:accept, so this makes any bind calls occur
Op vrijdag 26 augustus 2005 19:54, schreef Daniel Henninger:
Is there something wrong
with their implementation that doesn't scale away from jabberd2? It
looked pretty simple and right to the point to me.
Some questions:
* Is it secure that all components can open that many connections as
ahh, yes, i did debug this, and now i come and read email
I've managed to get it to take the binding *yay*, it was a matter of
sticking the namespace in right :-) also I found I have to use sasl,
and I can't use the old 'handshake' method to connect, does this sound
right?
also moving from
Hey Daniel,
The disco packet that Jive Messenger is sending to the newly connected
external component is meant for discovering if a new item should be added to
the disco#items packet that the server sends back when someone tries to
discover the server's items. So that disco info is not being
Gaston Dombiak wrote:
Hey Daniel,
The disco packet that Jive Messenger is sending to the newly connected
external component is meant for discovering if a new item should be added to
the disco#items packet that the server sends back when someone tries to
discover the server's items. So that
Well it would be usefull to be able to use more than 1 domain per
connection, and the only way that it's going to work
cross-implementation is if it becomes a proper JEP right?
On 25/08/05, Stephen Marquard [EMAIL PROTECTED] wrote:
Gaston Dombiak wrote:
Hey Daniel,
The disco packet that
I wholeheartedly agree! My particular software, for example, would
benefit greatly from it due to the way AIM handles it's chat exchanges.
IE, it would be very helpful for me to be able to say that I am all of the
following:
aim.jabber.foo.org
chatrooms.aim.jabber.foo.org
On Thursday August 25 2005 19:03, Stephen Marquard wrote:
Gaston Dombiak wrote:
Hey Daniel,
The disco packet that Jive Messenger is sending to the newly connected
external component is meant for discovering if a new item should be added
to the disco#items packet that the server sends
I've just had a look on jabberd2, and it's possible to half get this
to work using aliases. The only problem being that the node is added
to the server's disco list.
I spoke to stephen, and I think I'm going to have a look at
implementing the bind jep in xmpppy to see if i can get the yahoo
13 matches
Mail list logo
