I have built Red Hat packages of PyMSNt 0.9.5 for Fedora Core 3, which includes an init script for /etc/init.d , tested on SUCS' Jabber server. Currently the intall scripts do not enable automatic startup (since I have no way to test this); to enable it, something like ``chkconfig --add PyMSNt'' should work. The RPMs are available from the following sources; feel free to publish them yourselves.
ftp://sucs.org/pub/linux/PyMSNt-0.9.5-fc3.1.noarch.rpm ftp://sucs.org/pub/linux/PyMSNt-0.9.5-fc3.1.src.rpm The first is probably the one you want. Enjoy :) -- Peter Berry, SUCS Ex-Treasurer <[EMAIL PROTECTED]> (email and Jabber) From [EMAIL PROTECTED] Fri Sep 23 22:21:48 2005 From: [EMAIL PROTECTED] (Norman Rasmussen) Date: Fri Sep 23 22:21:50 2005 Subject: [py-transports] PyMSNt 0.10-rc3 In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> I have alpha patches for jabberd2's component protocol for xmpp.py. Is http://jabberd.jabberstudio.org/dev/docs/component.shtml the same as XCP? also, when you did the jabberd2 mods, are you talking about anything on http://j2.openaether.org/mediawiki/index.php/Clustering or have you written your own mods? (if so you should probably put a note up on the wiki talk page about it) I noticed that the avatar branch of PyMSNt has a XCP option, would this mean that it requires no furthur changes, or does it still need more tweaking? On 23/09/05, Gonzalo Barrio <[EMAIL PROTECTED]> wrote: > This things has to be done on the PyMSN/PyAIM/PyICQ side. I'm gonna do > this on PyMSN and send the changes to James, but all the other transports ? > Something is done in PyMSN to make it work on XCP, extend this to > jabberd2 component is not so dificult. > > Thanks again. > > Gonzalo Barrio Linares. > > > Norman Rasmussen wrote: > > >To fix this issue, you need to bind to your cluster domain from the > >clustering component. see > >http://jabberd.jabberstudio.org/dev/docs/component.shtml for more > >info. > > > >On 23/09/05, Gonzalo Barrio <[EMAIL PROTECTED]> wrote: > > > > > >>Well I take off the restriction in jabberd2 and all start working fine. > >>So I going to make a tar.gz and share my cluster component. (Written the > >>JCR) > >> > >>Thanks Pedro. > >> > >>Gonzalo Barrio wrote: > >> > >> > >> > >>>Ok, I finished the C component that made the clustering feature. It's > >>>simple but I can't make it work fine, because of a restriction in > >>>jabberd2. > >>>One component can't insert a packet as another. Here is an example > >>> > >>>I setup 2 PyMSN components: > >>> msn-1.hq.novamens.com > >>> msn-2.hq.novamens.com > >>> > >>>And the cluster component as: > >>> msn.hq.novamens.com > >>> > >>>Start up all three components (first the transports) and then I get > >>>this message from the router component of jabberd2: > >>> > >>>sx (io.c:205) decoded read data (574 bytes): <iq > >>>from='msn.hq.novamens.com' type='result' to='hq.novamens.com'><query > >>>xmlns='http://jabber. > >>>org/protocol/disco#info'><identity category='gateway' type='msn' > >>>name='MSN Transport'/><identity category='conference' type='text' > >>>name='MS > >>>N Transport Chatrooms'/><feature > >>>var='http://jabber.org/protocol/disco'/><feature > >>>var='jabber:x:conference'/><feature var='jabber:iq:confer > >>>ence'/><feature var='jabber:iq:register'/><feature > >>>var='jabber:iq:gateway'/><feature var='jabber:iq:version'/><feature > >>>var='http://jabber.o > >>>rg/protocol/commands'/><feature var='vcard-temp'/></query></iq> > >>>sx (io.c:70) completed nad: <iq xmlns='jabber:component:accept' > >>>to='hq.novamens.com' type='result' from='msn.hq.novamens.com'><query > >>>xmlns= > >>>'http://jabber.org/protocol/disco#info'><identity name='MSN Transport' > >>>type='msn' category='gateway'/><identity name='MSN Transport Chatroo > >>>ms' type='text' category='conference'/><feature > >>>var='http://jabber.org/protocol/disco'/><feature > >>>var='jabber:x:conference'/><feature var='j > >>>abber:iq:conference'/><feature var='jabber:iq:register'/><feature > >>>var='jabber:iq:gateway'/><feature var='jabber:iq:version'/><feature var=' > >>>http://jabber.org/protocol/commands'/><feature > >>>var='vcard-temp'/></query></iq> > >>>sx (chain.c:119) calling nad read chain > >>>sx (io.c:124) tag 22 event 6 data 0x80c2608 > >>>Fri Sep 23 16:06:45 2005 router.c:691 packet from legacy component, > >>>munging it > >>>Fri Sep 23 16:06:45 2005 router.c:373 unicast route from > >>>msn.hq.novamens.com to hq.novamens.com > >>>Fri Sep 23 16:06:45 2005 [notice] [192.168.1.4, port=27769] tried to > >>>send a packet from 'msn.hq.novamens.com', but that name is not bound t > >>>o this component > >>>Fri Sep 23 16:06:45 2005 router.c:321 packet for legacy component, > >>>munging > >>>sx (chain.c:106) calling nad write chain > >>>sx (io.c:369) queueing for write: <iq xmlns='jabber:client' > >>>to='hq.novamens.com' type='error' from='msn.hq.novamens.com'><error > >>>type='cance > >>>l' code='503'><service-unavailable > >>>xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/></error><query > >>>xmlns='http://jabber.org/protocol/disco#info > >>>'><identity name='MSN Transport' type='msn' > >>>category='gateway'/><identity name='MSN Transport Chatrooms' > >>>type='text' category='conference'/ > >>> > >>> > >>>><feature var='http://jabber.org/protocol/disco'/><feature > >>>> > >>>> > >>>var='jabber:x:conference'/><feature > >>>var='jabber:iq:conference'/><feature var='ja > >>>bber:iq:register'/><feature var='jabber:iq:gateway'/><feature > >>>var='jabber:iq:version'/><feature > >>>var='http://jabber.org/protocol/commands'/> > >>><feature var='vcard-temp'/></query></iq> > >>> > >>> > >>>Pedro do you know of some solution, or XCP does not restrict this ? > >>> > >>> > >>>Thanks, > >>> > >>>Gonzalo Barrio Linares > >>> > >>>PD: If everything works fine I 'm going to publish this. > >>> > >>>Pedro Melo wrote: > >>> > >>> > >>> > >>>>Hi, > >>>> > >>>>On Sep 15, 2005, at 8:36 PM, Gonzalo Barrio wrote: > >>>> > >>>> > >>>> > >>>>>Pedro, how many concurrent users have in sapo ? > >>>>> > >>>>> > >>>> > >>>>couple of thousands. > >>>> > >>>> > >>>> > >>>>>Are you using this clustering feature ? > >>>>> > >>>>> > >>>> > >>>>I'm moving today to cluster: several instances of pyMSNt > >>>>load-balanced by JID. > >>>> > >>>>The source code will be available (probably GPL) sometime this > >>>>weekend. It works for me now. It was written in-house, aroun 160 > >>>>lines of perl code, mostly error recovery and startup. The real > >>>>loadbalancing is around 3 or 4 lines :) > >>>> > >>>> > >>>> > >>>>>What hard and soft ? > >>>>>I mean msn1, msn2, msn3 ...... all reponding msn.im.sapo.com.pt, > >>>>>because > >>>>>I think that I can add this feature on jabberd2 modifying some > >>>>>things on > >>>>>the router and sm component. In this way, we can clusterize all kind of > >>>>>components (except mu-conference I think again) > >>>>> > >>>>> > >>>> > >>>>Ok. I can identify 3 types of balancing you need to cover all the > >>>>situations I faced. Those are: > >>>> - stateless: you don't care where the stanza's go, just round-robin, > >>>>least load, whatever, distribute them; > >>>> - statefull based on 'from': my packets must go to the same > >>>>instance, like MSN/AIM/ICQ, etc. Basically, any situation where the > >>>>component keeps a session for you. > >>>> - statefull based on 'to': text conferencing. you can have several > >>>>rooms, and some rooms go to chat1 and others go to chat2. Pubsub > >>>>jep60 might also applied, not a problem for us just yet. > >>>> > >>>>Also, right now, I don't care if the instances are up or down. Our > >>>>balancer get's a packet, hashes the jid to a integer, modulus number > >>>>of instances, and forwards (using <route>) the original stanza to the > >>>>choosen destination. > >>>> > >>>>The only difference between those three types of algorithm above is > >>>>the field that you use to distribute the stanzas. > >>>> > >>>>I don't think you need to modify anything on the server. You only > >>>>need a component that takes ownership of your main domain name > >>>>(msn.im.sapo.pt) in our case, and start N instances of your component. > >>>> > >>>>One think that is required: each component must respond to the main > >>>>domain name and a secondary name. In some server (like XCP that we > >>>>use), you can have a linkname (based on the ID) and a host filter. > >>>>Our balancer needs that. We send the stanzas to the linkname, and the > >>>>stanzas include the main domain name. > >>>> > >>>>Notice that our code does not do any kind of rewriting. There is no > >>>>need to do it. Also, it's just a normal component with a single TCP > >>>>connection to the server. It does not connect directly to the other > >>>>instances. All the traffic is through the server. > >>>> > >>>>Also, notice that only the stanzas to the main domain go through the > >>>>balancer. The replies flow directly from the component instances to > >>>>the client. > >>>> > >>>>If you server does not trust the components and checks all the > >>>>stanzas received to see if they match the from with the linkname, for > >>>>example, you will have trouble. > >>>> > >>>>Finally, the only requirements on the component that you wish to > >>>>balance are: > >>>> - they need to support linkname and hostname: pyMSNt supports that > >>>>with the <useXCP> tag, that's your linkname; > >>>> - they need to support <route> stanzas: simple really, just drop the > >>>><route></route> and use the XML inside as if it came from the socket. > >>>> > >>>>Regarding jabberd2, my suggestion would be that you don't implement > >>>>this inside the server, but as a external component. Oh, and if you > >>>>write something like this in C, I will be extremely interested :)... > >>>>On our roadmap is moving xbalance.pl to C, but only if we need it. > >>>> > >>>> > >>>> > >>>> > >>>>>Then only thing I don't want to do is to reinvent the weel..... :-) > >>>>> > >>>>> > >>>> > >>>>Same here. I searched the web for something like this and found > >>>>nothing, so I just coded it. > >>>> > >>>>I think that if we can agree on a spec we can build one of these > >>>>components in C and use it with all the jabber servers that support > >>>>JEP-0100. > >>>> > >>>>That would be cool. > >>>> > >>>>My problem with C, btw, is that I don't know which library to use as > >>>>a base of this component. If you have some ideas about that, I would > >>>>love to ear them. > >>>> > >>>>Thanks, > >>>>-- > >>>>HIId: Pedro Melo > >>>>SMTP: [EMAIL PROTECTED] > >>>>XMPP: [EMAIL PROTECTED] > >>>> > >>>>_______________________________________________ > >>>>py-transports mailing list > >>>>py-transports@blathersource.org > >>>>http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports > >>>> > >>>> > >>>> > >>>_______________________________________________ > >>>py-transports mailing list > >>>py-transports@blathersource.org > >>>http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports > >>> > >>> > >>> > >>_______________________________________________ > >>py-transports mailing list > >>py-transports@blathersource.org > >>http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports > >> > >> > >> > > > > > >-- > >- 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 > > > > > > > > > -- - Norman Rasmussen - Email: [EMAIL PROTECTED] - Home page: http://norman.rasmussen.co.za/ From [EMAIL PROTECTED] Fri Sep 23 22:45:55 2005 From: [EMAIL PROTECTED] (Gonzalo Barrio) Date: Fri Sep 23 22:42:42 2005 Subject: [py-transports] PyMSNt 0.10-rc3 In-Reply-To: <[EMAIL PROTECTED]> References: <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> <[EMAIL PROTECTED]> Message-ID: <[EMAIL PROTECTED]> Well, the only modification that I did to jabberd2 is disabled the check that does not permit the send :-P Bad thing. I don't have XCP but I think that if you have it you will not require more changes, because Pedro Melo has a cluster module written in perl that works with that. I make the same component but in C, just for performance. Actually it works in jabberd2 with some lines of router.c commented out, but if James does not make the jabberd2 component changes I will. On monday I send the component, if anyone need it early, I send a copy, but I like to test it a little more. It support the three kinds of cluster said by Pedro: - Sateful by the "from" part (For any kind of transport) - Sateful by the "to" part (For muc) - Sateless (for juds or other components that not require an interaction between both parts, client and component) Saludos, Gonzalo Barrio Linares. Norman Rasmussen wrote: >I have alpha patches for jabberd2's component protocol for xmpp.py. > >Is http://jabberd.jabberstudio.org/dev/docs/component.shtml the same as XCP? > >also, when you did the jabberd2 mods, are you talking about anything >on http://j2.openaether.org/mediawiki/index.php/Clustering or have you >written your own mods? (if so you should probably put a note up on >the wiki talk page about it) > >I noticed that the avatar branch of PyMSNt has a XCP option, would >this mean that it requires no furthur changes, or does it still need >more tweaking? > >On 23/09/05, Gonzalo Barrio <[EMAIL PROTECTED]> wrote: > > >>This things has to be done on the PyMSN/PyAIM/PyICQ side. I'm gonna do >>this on PyMSN and send the changes to James, but all the other transports ? >>Something is done in PyMSN to make it work on XCP, extend this to >>jabberd2 component is not so dificult. >> >>Thanks again. >> >>Gonzalo Barrio Linares. >> >> >>Norman Rasmussen wrote: >> >> >> >>>To fix this issue, you need to bind to your cluster domain from the >>>clustering component. see >>>http://jabberd.jabberstudio.org/dev/docs/component.shtml for more >>>info. >>> >>>On 23/09/05, Gonzalo Barrio <[EMAIL PROTECTED]> wrote: >>> >>> >>> >>> >>>>Well I take off the restriction in jabberd2 and all start working fine. >>>>So I going to make a tar.gz and share my cluster component. (Written the >>>>JCR) >>>> >>>>Thanks Pedro. >>>> >>>>Gonzalo Barrio wrote: >>>> >>>> >>>> >>>> >>>> >>>>>Ok, I finished the C component that made the clustering feature. It's >>>>>simple but I can't make it work fine, because of a restriction in >>>>>jabberd2. >>>>>One component can't insert a packet as another. Here is an example >>>>> >>>>>I setup 2 PyMSN components: >>>>> msn-1.hq.novamens.com >>>>> msn-2.hq.novamens.com >>>>> >>>>>And the cluster component as: >>>>> msn.hq.novamens.com >>>>> >>>>>Start up all three components (first the transports) and then I get >>>>>this message from the router component of jabberd2: >>>>> >>>>>sx (io.c:205) decoded read data (574 bytes): <iq >>>>>from='msn.hq.novamens.com' type='result' to='hq.novamens.com'><query >>>>>xmlns='http://jabber. >>>>>org/protocol/disco#info'><identity category='gateway' type='msn' >>>>>name='MSN Transport'/><identity category='conference' type='text' >>>>>name='MS >>>>>N Transport Chatrooms'/><feature >>>>>var='http://jabber.org/protocol/disco'/><feature >>>>>var='jabber:x:conference'/><feature var='jabber:iq:confer >>>>>ence'/><feature var='jabber:iq:register'/><feature >>>>>var='jabber:iq:gateway'/><feature var='jabber:iq:version'/><feature >>>>>var='http://jabber.o >>>>>rg/protocol/commands'/><feature var='vcard-temp'/></query></iq> >>>>>sx (io.c:70) completed nad: <iq xmlns='jabber:component:accept' >>>>>to='hq.novamens.com' type='result' from='msn.hq.novamens.com'><query >>>>>xmlns= >>>>>'http://jabber.org/protocol/disco#info'><identity name='MSN Transport' >>>>>type='msn' category='gateway'/><identity name='MSN Transport Chatroo >>>>>ms' type='text' category='conference'/><feature >>>>>var='http://jabber.org/protocol/disco'/><feature >>>>>var='jabber:x:conference'/><feature var='j >>>>>abber:iq:conference'/><feature var='jabber:iq:register'/><feature >>>>>var='jabber:iq:gateway'/><feature var='jabber:iq:version'/><feature var=' >>>>>http://jabber.org/protocol/commands'/><feature >>>>>var='vcard-temp'/></query></iq> >>>>>sx (chain.c:119) calling nad read chain >>>>>sx (io.c:124) tag 22 event 6 data 0x80c2608 >>>>>Fri Sep 23 16:06:45 2005 router.c:691 packet from legacy component, >>>>>munging it >>>>>Fri Sep 23 16:06:45 2005 router.c:373 unicast route from >>>>>msn.hq.novamens.com to hq.novamens.com >>>>>Fri Sep 23 16:06:45 2005 [notice] [192.168.1.4, port=27769] tried to >>>>>send a packet from 'msn.hq.novamens.com', but that name is not bound t >>>>>o this component >>>>>Fri Sep 23 16:06:45 2005 router.c:321 packet for legacy component, >>>>>munging >>>>>sx (chain.c:106) calling nad write chain >>>>>sx (io.c:369) queueing for write: <iq xmlns='jabber:client' >>>>>to='hq.novamens.com' type='error' from='msn.hq.novamens.com'><error >>>>>type='cance >>>>>l' code='503'><service-unavailable >>>>>xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/></error><query >>>>>xmlns='http://jabber.org/protocol/disco#info >>>>>'><identity name='MSN Transport' type='msn' >>>>>category='gateway'/><identity name='MSN Transport Chatrooms' >>>>>type='text' category='conference'/ >>>>> >>>>> >>>>> >>>>> >>>>>><feature var='http://jabber.org/protocol/disco'/><feature >>>>>> >>>>>> >>>>>> >>>>>> >>>>>var='jabber:x:conference'/><feature >>>>>var='jabber:iq:conference'/><feature var='ja >>>>>bber:iq:register'/><feature var='jabber:iq:gateway'/><feature >>>>>var='jabber:iq:version'/><feature >>>>>var='http://jabber.org/protocol/commands'/> >>>>><feature var='vcard-temp'/></query></iq> >>>>> >>>>> >>>>>Pedro do you know of some solution, or XCP does not restrict this ? >>>>> >>>>> >>>>>Thanks, >>>>> >>>>>Gonzalo Barrio Linares >>>>> >>>>>PD: If everything works fine I 'm going to publish this. >>>>> >>>>>Pedro Melo wrote: >>>>> >>>>> >>>>> >>>>> >>>>> >>>>>>Hi, >>>>>> >>>>>>On Sep 15, 2005, at 8:36 PM, Gonzalo Barrio wrote: >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Pedro, how many concurrent users have in sapo ? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>couple of thousands. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Are you using this clustering feature ? >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>I'm moving today to cluster: several instances of pyMSNt >>>>>>load-balanced by JID. >>>>>> >>>>>>The source code will be available (probably GPL) sometime this >>>>>>weekend. It works for me now. It was written in-house, aroun 160 >>>>>>lines of perl code, mostly error recovery and startup. The real >>>>>>loadbalancing is around 3 or 4 lines :) >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>What hard and soft ? >>>>>>>I mean msn1, msn2, msn3 ...... all reponding msn.im.sapo.com.pt, >>>>>>>because >>>>>>>I think that I can add this feature on jabberd2 modifying some >>>>>>>things on >>>>>>>the router and sm component. In this way, we can clusterize all kind of >>>>>>>components (except mu-conference I think again) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>Ok. I can identify 3 types of balancing you need to cover all the >>>>>>situations I faced. Those are: >>>>>>- stateless: you don't care where the stanza's go, just round-robin, >>>>>>least load, whatever, distribute them; >>>>>>- statefull based on 'from': my packets must go to the same >>>>>>instance, like MSN/AIM/ICQ, etc. Basically, any situation where the >>>>>>component keeps a session for you. >>>>>>- statefull based on 'to': text conferencing. you can have several >>>>>>rooms, and some rooms go to chat1 and others go to chat2. Pubsub >>>>>>jep60 might also applied, not a problem for us just yet. >>>>>> >>>>>>Also, right now, I don't care if the instances are up or down. Our >>>>>>balancer get's a packet, hashes the jid to a integer, modulus number >>>>>>of instances, and forwards (using <route>) the original stanza to the >>>>>>choosen destination. >>>>>> >>>>>>The only difference between those three types of algorithm above is >>>>>>the field that you use to distribute the stanzas. >>>>>> >>>>>>I don't think you need to modify anything on the server. You only >>>>>>need a component that takes ownership of your main domain name >>>>>>(msn.im.sapo.pt) in our case, and start N instances of your component. >>>>>> >>>>>>One think that is required: each component must respond to the main >>>>>>domain name and a secondary name. In some server (like XCP that we >>>>>>use), you can have a linkname (based on the ID) and a host filter. >>>>>>Our balancer needs that. We send the stanzas to the linkname, and the >>>>>>stanzas include the main domain name. >>>>>> >>>>>>Notice that our code does not do any kind of rewriting. There is no >>>>>>need to do it. Also, it's just a normal component with a single TCP >>>>>>connection to the server. It does not connect directly to the other >>>>>>instances. All the traffic is through the server. >>>>>> >>>>>>Also, notice that only the stanzas to the main domain go through the >>>>>>balancer. The replies flow directly from the component instances to >>>>>>the client. >>>>>> >>>>>>If you server does not trust the components and checks all the >>>>>>stanzas received to see if they match the from with the linkname, for >>>>>>example, you will have trouble. >>>>>> >>>>>>Finally, the only requirements on the component that you wish to >>>>>>balance are: >>>>>>- they need to support linkname and hostname: pyMSNt supports that >>>>>>with the <useXCP> tag, that's your linkname; >>>>>>- they need to support <route> stanzas: simple really, just drop the >>>>>><route></route> and use the XML inside as if it came from the socket. >>>>>> >>>>>>Regarding jabberd2, my suggestion would be that you don't implement >>>>>>this inside the server, but as a external component. Oh, and if you >>>>>>write something like this in C, I will be extremely interested :)... >>>>>>On our roadmap is moving xbalance.pl to C, but only if we need it. >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>>>Then only thing I don't want to do is to reinvent the weel..... :-) >>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>Same here. I searched the web for something like this and found >>>>>>nothing, so I just coded it. >>>>>> >>>>>>I think that if we can agree on a spec we can build one of these >>>>>>components in C and use it with all the jabber servers that support >>>>>>JEP-0100. >>>>>> >>>>>>That would be cool. >>>>>> >>>>>>My problem with C, btw, is that I don't know which library to use as >>>>>>a base of this component. If you have some ideas about that, I would >>>>>>love to ear them. >>>>>> >>>>>>Thanks, >>>>>>-- >>>>>>HIId: Pedro Melo >>>>>>SMTP: [EMAIL PROTECTED] >>>>>>XMPP: [EMAIL PROTECTED] >>>>>> >>>>>>_______________________________________________ >>>>>>py-transports mailing list >>>>>>py-transports@blathersource.org >>>>>>http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>_______________________________________________ >>>>>py-transports mailing list >>>>>py-transports@blathersource.org >>>>>http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports >>>>> >>>>> >>>>> >>>>> >>>>> >>>>_______________________________________________ >>>>py-transports mailing list >>>>py-transports@blathersource.org >>>>http://www.modevia.com/cgi-bin/mailman/listinfo/py-transports >>>> >>>> >>>> >>>> >>>> >>>-- >>>- 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 >>> >>> >>> >>> >>> >> >> >> > > >-- >- 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 > > >
