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&group=component&component=xmpppy&order=priority

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/
_______________________________________________
Gajim-devel mailing list
Gajim-devel@gajim.org
https://lists.gajim.org/cgi-bin/listinfo/gajim-devel

Reply via email to