Gajim-devel June 2008

gajim-devel@gajim.org

10 participants
12 discussions

Gajim-svn and problem with SOCKS5 proxy
by Marcin Zajączkowski 03 Jul '08

03 Jul '08

Hello, I'm unable to use SOCKS5 proxy (tested with privoxy & tor and Gajim-svn - 20080604 night build). Every time I try to connect I see on my console (gajim.py -v): DEBUG: CONNECTproxy start Plugging <common.xmpp.transports_nb.NBSOCKS5PROXYsocket instance at 0x98015cc> into <common.xmpp.client_nb.NonBlockingClient instance at 0x904e08c> DEBUG: CONNECTproxy start Proxy server contacted, performing authentification DEBUG: CONNECTproxy sent and nothing more happens. I tried with using HTTP_PROXY environment variable and manual proxy definition as well. I haven't find any similar tickets in trac. Maybe you know what can be wrong? Is it possible to increase a logging level to see more details about that? Regards Marcin

2 8

blocking getaddrinfo
by Tomas Karasek 01 Jul '08

01 Jul '08

Hi, I'm trying to get rid of the GUI-blocking timeout that occurs on getaddrinfo() during connecting to XMPP server when network is down. In such case, getaddrinfo blocks for quite a long time and roster window doesn't respond. It happens on connect after executing Gajim, and also when Gajim disconnects due to a network failiure and then tries to reconnect (and network is still down). I was talking about that with Asterix and because we didn't find any AAAA-capable asynchronous python dns library, we came up with following: Because SRV requests are done asynchronously via nslookup in pipe polled in IdleQueue (src/common/nslookup.py), it's possible to detect that DNS server is not available from result of asynchronous SRV request. And - if we know that DNS SRV request failed, then don't do the getaddrinfo call. But now I found out that there is a short blocking timeout when closing pipe with running nslookup - on self.pipe.close(), so this is not a solution for GUI blocking on connect. I already tried putting getaddrinfo to separate thread, but it just didn't work for me - the thread was waiting even after a successful gai call... As for dns libraries - adns can't do AAAA requests, pydns and dnspython can't operate asynchronously. What I'm looking for is either - some elegant way how to do both A and AAAA requests asynchronously (like nonblocking getaddrinfo) which would be a nice solution or - nonblocking detect that network is down which would allow to avoid needless call of getaddrinfo (temporary solution until some suitable library appears) Do you have any ideas/suggestions on this? rgds, tomk -- Tomas Karasek jabber: tom.to.the.k at jabber.cz GSoC blog: http://tomk-soc08.blogspot.com/

5 8

dev-meeting
by Yann Leboulanger 28 Jun '08

28 Jun '08

Hi all, Last dev meeting was interesting and usefull. So why not another one ? What about monday 30th June, 7pm GMT (9pm CEST) ? -- Yann

4 4

Code Migration and Modernization
by Stephan Erb 27 Jun '08

27 Jun '08

Hi, I just thought the following PEP is worth a read for all of us. We should keep it in mind when writing new code and when working on existing pieces. http://www.python.org/dev/peps/pep-0290/ Best Regards, steve

1 0

Crypto authentication UI
by Brendan Taylor 13 Jun '08

13 Jun '08

We've got two different end-to-end encryption methods and at least one more on the way (not to mention XTLS, which looks like it's going to be the new officially-blessed e2ee XEP...) It would be nice to have a consistent way of telling the user whether they've authenticated the remote user's identity. The Esessions implementation pops up a dialog before it lets you chat if you haven't verified the remote user's identity. It's not a very good interface. <http://trac.gajim.org/ticket/3468> I like the way OTR did it; it tells you in the ChatControl whether you've verified identity or not, but doesn't interrupt anything. There's a menu item that pops up a dialog if you want to do a verification. My suggestion: If you're in an encrypted chat but you haven't verified the identity, overlay a big red question mark on the encryption lock icon in the ChatControl and put a tooltip on it explaining the problem. Clicking on the question mark pops up a verification dialog (specific to whatever end-to-end encryption protocol you're using). Good idea? Does it make the potential problem obvious enough to the user? Is there a better symbol/place to put the symbol/place to put the button for the dialog? How does the OpenPGP code handle an unknown key?

3 2

BOSH implementation and xmpppy testing
by Tomas Karasek 13 Jun '08

13 Jun '08

Hi everyone, I'm working on BOSH implementation in Gajim and I would like to discuss few issues. Just to outline the context: When using BOSH connection, client has to connect to Connection Manager (sth like HTTP server or proxy) and CM then connects to XMPP server. In general, client-CM traffic are XMPP messages wrapped in HTTP POST requests/HTTP responses. For sake of server-initiated XMPP messages there should be always a HTTP request pending in client-CM connection. Connection Manager doesn't have to be capable of HTTP Pipelining or even persistent connections (case of ejabberd) and then, more TCP connections can be open between client and CM at a same time. (more on http://www.xmpp.org/extensions/xep-0124.html#technique) I wanted to keep the Connection class untouched and create a BOSHClient class that holds one or two TCP connections to CM (with same interface as NonBlockingClient holding one TCP connection to XMPP server). Turned out it's a bad idea because in current Gajim xmpppy, only one instance of a kind (e.g. NonBlockingTcp) can be plugged to Client and moreover, other stuff plugged to Client (dispatcher, sasl auth, tls) use exported method of Transport (resp. Dispatcher) for sending data (and there should be some adjustments before putting data on wire for BOSH messages. And the other way around, some peel-off before passing received data up to Connection). So now I'm thinking about BOSH *Transport* implementing PlugIn interface, posessing up to two Tcp connections (IdleObjects to be plugged to IdleQueue). BOSHTransport would be plugged to BOSHClient or NonBlockingClient, depending on whether there will be any need for BOSHClient. I see two ways of implementing the BOSHTransport: * Use NonBlockingTcp as TCP connection - In this case, some changes have to be done in NonBlockingTcp: - sending of </stream> on TCP disconnecting would have to move to Client or to Connection - stream is closed differently in BOSH - loop of _do_connects over IP addresses from getaddrinfo() also to Client - considering the nonpersisent HTTP - after TCP disconnect, client should connect to CM where its session is already opened (to the same IP), plus no need for DNS requests every time - maybe some more things I don't see right now There is advantage of reusing the HTTPProxy and SOCKS5Proxy classes derived from NonBlockingTcp - same could be used for XMPP over proxy as for BOSH over proxy. * Write BOSHTransport from scratch - In this case, I would write new TCP/HTTP wrappers implementing the IdleObject interface. There could probably be some code duplication between NonBlockingTcp and BOSHTransport. Another proxy wrappers have to take place. I'm up for the first option. Nevertheless this is a minor issue, change of option to another takes low effort. I'm just interested in your opinions about the current state of Gajim xmpppy and improvement suggestions I could consider. I went through http://trac.gajim.org/query?status=new&status=assigned&status=reopened&grou… and I'll try to remove the unused code for starters. Another topic is xmpppy testing - If I was about to refactor NonBlockingTcp class, I would probably first write a unit test for NonBlockingClient to avoid unintentional screw up of something. I'm not very familiar with unit testing but I quickly read unittest python manual and it could be done like this: initialize IdleQueue and callbacks in setUp() method, and then calling functions for connecting, authentication, sending a message etc. interleaved with IdleQueue.process() calls. Is NonBlockingClient good place for Gajim unit testing? Thanks for reading up to here :) Cheers, tomk -- Tomas Karasek jabber: tom.to.the.k at jabber.cz GSoC blog: http://tomk-soc08.blogspot.com/

3 2

Regular Meetings
by Stephan Erb 12 Jun '08

12 Jun '08

As far as I am concerned the meeting last night was a success. What about schedule regular meetings? Lets say every two weeks? Best steve

2 1

Meeting Minutes 13.06.2008
by Stephan Erb 12 Jun '08

12 Jun '08

We decided to release an Alpha on 11.7.2008. Furthermore: OSX: • no official support, no binaries • we can keep it in the tarball as it is • js might work on some further improvements CAPS • assigned to Asterix and JS Connection SSL Problems • assigned to Asterix Async DNS • not planned for 0.12 Roster Bugs • assigned to jim and steve-e Session centric • assigned to bct Did I miss anything?

1 0

"Fixing Broken Windows"
by Stephan Erb 07 Jun '08

07 Jun '08

While thinking about testability I also wondered about what we shall do with code that is not just a little bit buggy but worse. Think of a house that was once nice and tidy and is now totally rotten. A window was smashed and nobody repaired it. It is the same with code and we have to fix broken windows when they occur. A broken window is everything that nobody understands, doesn't work properly or simply is implemented in a very ugly fashion. I propose to remove such code for now and to come back on it in a later release cycle (maybe as a plugin). Of course this is not always possible but we should really consider it, IMHO. When I look at gajim, I see the following broken windows: - OSX integration - OTR-Encryption - GPG-Encryption Nobody should feel accused or attacked, it is not meant personally but I only want you all think about what we have at the moment and what we really want or what our goals should be. And hey, never forget, I smashed the biggest window - the roster.... What do you think? Best, steve

11 37

Testing Gajim?
by Brendan Taylor 07 Jun '08

07 Jun '08

Has anybody given thought to an automated test suite for Gajim? It would make it a lot easier to refactor parts of the code without introducing bugs that require a lot of manual testing to find. Getting to a point where the suite is complete enough to be useful will be difficult, but even the process of making Gajim testable would help reduce some of the coupling between modules. I think the best way to start is find a place in the code that it would be easy to write tests for and work out from there. Is there any interest in this? Any suggestions about a good place to start writing tests against?

3 6

2026

2025

2024

2023

2022

2021

2020

2019

2018

2017

2016

2015

2014

2013

2012

2011

2010

2009

2008

2007

2006

Gajim-devel June 2008