IBB status

I've been meaning to write my report earlier, but I thought I would be finish with IBB by monday. At that point I had successfully transfered files over IBB doing a transport-replace.

The thing was that I was forcing Gajim to do a transport-replace right after the jingle session initiates. That was good for testing, but in the real world scenario, transport-replace would only come after Gajim recieves the following stanza:

<iq from='target@example.org/bar'
    id='hu3vax16'
    to='requester@example.com/foo'
    type='error'>
  <error type='cancel'>
    <item-not-found 
        xmlns='urn:ietf:params:xml:ns:xmpp-stanzas'/>
  </error>
</iq>

I encountered an array of minor problems related to the JingleFT branch, that have prevented me from successfully test for the IBB fallback. Hopefully they will be sorted out by the end of this week.

wiki ready

The wiki for Stream Management can be found here.

Resumption is working

That's a video with stream management resumption working. To tell what is going on, you need to put it in full screen.




All left to do is to test and then write some documentation on it.

Here's the diagram for the smacks class.

I will give a more detailed information about resumption in the wiki, and hopefully by next week I'll be implementing the jingle FT.

Starting to implement

So, Gajim can basically send and request acks to a server. I haven't through fully tested it, but I will leave that for latter. Right now I'm focusing on resumption, which is harder because it changes the way Gajim connects to the server if it knows that resumption is accepted by the server.

For efficient acking the specification shows this example:

C: <enable/>
S: <enabled stanzas='5'/>
C: <message/>
C: <message/>
C: <message/>
C: <message/>
C: <message/>
C: <r/>
S: <a h='4'/>
C: <message/>
C: <message/>
C: <message/>
C: <message/>
C: <message/>
C: <r/>
S: <a h='9'/>

Which I find very weird that the server is the one who gets to set the interval in which the requests are sent. Since both, the sever and the client, can send and receive acks at any time, it doesn't makes sense that the server cares or has any say on how often the client sends acks.

So I made the judgment call to ignore this for now and let Gajim decide when it wants to send acks.