On 11/28/05, Daniel Henninger <[EMAIL PROTECTED]> wrote:
> > re: http://www.darkskies.za.net/~norman/jabber/pyaimt-jabberd2-
> > v1.patch
> >
> > I got JD2 components for pyaimt working.  I had to add a jabberd2 user
> > called 'aim.jabber.darkskies.za.net' and give it the same password as
> > my legacy user.  It would be nice if the sasl username was separately
> > configurable from the transport name.
>
> Glad to hear you found out how to fix it.  I don't see why it
> couldn't have a different sasl username.  (in fact, previously, I had
> an entirely different sasl username and password config option)
> Obviously I never completed that functionality for this release so
> nothing was ironed out in that arena.
I was just too lazy to add config options, etc.  It was easier to add
the user.  That being said, in the long run I'd like to be able to set
the username in pyaimt, so that I don't have to have a seperate
jabberd2 user for each transport.

> > Also I tried to tweak the disco items so that the chat host is 'under'
> > the main host.  The way disco is written atm, this makes the hash
> > pretty ugly.  This is probably not the best way to do it.
> > Additionally I have found that if you return no info when disco'ed is
> > from your main host (i.e. disco chatrooms.aim.jabber.darkskies.za.net
> > from darkskies.za.net)  then jabberd2 will not include the chatrooms
> > in your disco results.  I didn't find an easy way to hook this into
> > the existing disco structure.  (The addNode wants to call it's own
> > function which would only call discovery.onIq if the requestor is not
> > the server's jid).
>
> I actually like that it's not "under" aim.jabber.whatever and is
> shown as it's own separate entity.  Note that if you alias the
> chatrooms instance to the main instance, you can see them both in
> disco just fine.  Why does jabberd2 not show/explore both jid's if
> you bind as both using it's own component protocol?  I wouldn't
> really mind if it was under aim.jabber though, it's "not important"
> to me where it is exactly.  =)

yup, the jabberd2 component binding removes the need for the alias.  I
just prefer subdomain nodes to appear underneath the main domain node.
 That way everything is tucked away neatly and doesn't spammify the
root disco node.  (like the way i've done my
yahoo.jabber.darkskies.za.net node)

> > Additionally I found a bug that kicks the transport off the server:
> > Try and search when you're not logged in.
>
> *chuckle*  Yes, I never did finish working out all of the bugs in the
> search functionality.  AIM's directory servers upset me.  ;D  (they
> don't let me connect a good deal of the time)  That said, it's a
> surprise to me to hear that it does crash when you aren't logged in.
> At one point I specifically took care of that.  Guess I re-broke it.
> =(  Dooh.  Mind filing a bug report at blathersource.org?
>
> > Would it be possible to change it so that an exception doesn't boot
> > the entire component off the server when something goes wrong?  (or
> > get auto-reconnect working?)
>
> Depends on the nature of the exception I imagine.  Obivously not all
> exceptions boot the component.

mmm, was the searching while offline bug, pretty easy to duplicate. 
The exception seems to cause the transport to disconnect and
reconnect, but it seems to forget to re-auth, etc.

--
- Norman Rasmussen
 - Email: [EMAIL PROTECTED]
 - Home page: http://norman.rasmussen.co.za/
From [EMAIL PROTECTED]  Mon Nov 28 14:30:12 2005
From: [EMAIL PROTECTED] (Daniel Henninger)
Date: Mon Nov 28 14:30:20 2005
Subject: [py-transports] pyaimt and jabberd2 component protocol
In-Reply-To: <[EMAIL PROTECTED]>
References: <[EMAIL PROTECTED]>
        <[EMAIL PROTECTED]>
        <[EMAIL PROTECTED]>
Message-ID: <[EMAIL PROTECTED]>

>>> re: http://www.darkskies.za.net/~norman/jabber/pyaimt-jabberd2-
>>> v1.patch
>>>
>>> I got JD2 components for pyaimt working.  I had to add a jabberd2  
>>> user
>>> called 'aim.jabber.darkskies.za.net' and give it the same  
>>> password as
>>> my legacy user.  It would be nice if the sasl username was  
>>> separately
>>> configurable from the transport name.
>>
>> Glad to hear you found out how to fix it.  I don't see why it
>> couldn't have a different sasl username.  (in fact, previously, I had
>> an entirely different sasl username and password config option)
>> Obviously I never completed that functionality for this release so
>> nothing was ironed out in that arena.
> I was just too lazy to add config options, etc.  It was easier to add
> the user.  That being said, in the long run I'd like to be able to set
> the username in pyaimt, so that I don't have to have a seperate
> jabberd2 user for each transport.

What do you think about the password?  Originally, I had a separate  
config option for sasl username and password, but if I ask for a  
separate password from the "secret", then "secret" is never used.  So  
I figured, why am I bothering with that?  Why don't I just use  
"secret" as the sasl password.  What do you think about this?  I  
could change "useSASL" into a "saslUser" or something like that and  
change the check to be "is it empty or not".

>>> Also I tried to tweak the disco items so that the chat host is  
>>> 'under'
>>> the main host.  The way disco is written atm, this makes the hash
>>> pretty ugly.  This is probably not the best way to do it.
>>> Additionally I have found that if you return no info when  
>>> disco'ed is
>>> from your main host (i.e. disco  
>>> chatrooms.aim.jabber.darkskies.za.net
>>> from darkskies.za.net)  then jabberd2 will not include the chatrooms
>>> in your disco results.  I didn't find an easy way to hook this into
>>> the existing disco structure.  (The addNode wants to call it's own
>>> function which would only call discovery.onIq if the requestor is  
>>> not
>>> the server's jid).
>>
>> I actually like that it's not "under" aim.jabber.whatever and is
>> shown as it's own separate entity.  Note that if you alias the
>> chatrooms instance to the main instance, you can see them both in
>> disco just fine.  Why does jabberd2 not show/explore both jid's if
>> you bind as both using it's own component protocol?  I wouldn't
>> really mind if it was under aim.jabber though, it's "not important"
>> to me where it is exactly.  =)
>
> yup, the jabberd2 component binding removes the need for the alias.  I
> just prefer subdomain nodes to appear underneath the main domain node.
>  That way everything is tucked away neatly and doesn't spammify the
> root disco node.  (like the way i've done my
> yahoo.jabber.darkskies.za.net node)

Hrm.  Well ok.  I'm used to a bazillion things showing up in disco  
and so I didn't even think that it would be "prettier" if it were  
tucked away.  *ponder*

>>> Additionally I found a bug that kicks the transport off the server:
>>> Try and search when you're not logged in.
>>
>> *chuckle*  Yes, I never did finish working out all of the bugs in the
>> search functionality.  AIM's directory servers upset me.  ;D  (they
>> don't let me connect a good deal of the time)  That said, it's a
>> surprise to me to hear that it does crash when you aren't logged in.
>> At one point I specifically took care of that.  Guess I re-broke it.
>> =(  Dooh.  Mind filing a bug report at blathersource.org?
>>
>>> Would it be possible to change it so that an exception doesn't boot
>>> the entire component off the server when something goes wrong?  (or
>>> get auto-reconnect working?)
>>
>> Depends on the nature of the exception I imagine.  Obivously not all
>> exceptions boot the component.
>
> mmm, was the searching while offline bug, pretty easy to duplicate.
> The exception seems to cause the transport to disconnect and
> reconnect, but it seems to forget to re-auth, etc.

I think, if it's not using the jabber 2 component protocol, that it  
does reconnect properly after a crash like that.  I must have missed  
something.  Either way, I'll look into it.

BTW, I find it amusing that I left "jabber2.vorpalcloud.org" in  
main.py in the jabber component stuff.  ;)  Dooh.

Daniel


>
> --
> - Norman Rasmussen
>  - Email: [EMAIL PROTECTED]
>  - Home page: http://norman.rasmussen.co.za/
> _______________________________________________
> py-transports mailing list
> py-transports@blathersource.org
> http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports
>
>

Reply via email to