Gtalk and code progress report...

We have looked at the xml bouncing back and forth in Jabber. We have looked a lot on the xml between the jabbin client and the gtalk.google.com server(s). We needed to reverse engineer the GTalk jingle protocol, since we can not find it on the Internet. As mentioned in a previous post, Jabbin has a nice XML console feature, which is VERY usefull to us - both for testing stanzas and for seeing what is actually happening in the protocol.

But we have had some problems reproducing the XML bouncing due to a "weird" HEX number on the Jabber resource which only appears in Gaim/Pidgin and not in Jabbin.

We sought advice in the Jabber developer channel, and found that it was the google server that appended this hex number to the resource - depending on the authorization. This is the actual chat:

(11:31:30) tdh1976: Hi there, any1 who is a little familiar with the jabber implementation in Gaim/Pidgin?
(11:31:31) Alex left the room.
(11:32:58) tdh1976: Its because a number is append to the resource when we log on to the gtalk server using Gaim... and we really dont understand it!
(11:33:42) Asterix: tdh1976, it's not gaim, it's gtalk itself
(11:33:50) Spike: I think it's called "Resource binding".
(11:34:12) Asterix: in fact when a client connect, it requests a resourc, and the server return the resource it must use. gtalk adds a number at the end ... don't ask why ...
(11:42:23) tdh1976: why? :P
(11:42:51) tdh1976: we have been looking at jabbin and gaim and it is not there in jabbin
(11:44:08) Asterix: maybe jabbin shows the resource the user gave, but it's not the one used in gtalk server
(11:44:30) tdh1976: hmm ok that helped us a little. thx guys
(11:46:10) legoscia: hm¡Ä does gtalk add the number when the client uses legacy authentication? that seems hard to me¡Ä
(11:46:33) Kev: Jabbin is a fork of Psi before 0.10
(11:46:53) Kev: so it does legacy auth instead of sasl and so not resource binding
(11:47:25) Kev: and yes, google assigns the hex resources if the client supports resource binding and doesn't otherwise
(11:47:34) Kev: (and yes, that sounds pretty hard)
(11:47:48) tdh1976: but then again it explains a lot ;-)
(11:48:50) Alex entered the room.
(11:49:44) Alex: morning guys
(11:50:14) Kev: morning Alex
(11:52:00) Kev: (the reason for the hex appendage to resources is so google talk can track user sessions across their server farm, I've been told (I don't know how they manage this without resource binding))
hex-ressource

Drawback in the Jabber Pidgin implementation
We have now faced the first really big problem keeping our code strictly as a plugin. This is due to the way the Jabber protocol plugin is designed in Gaim/Pidgin. It returns an error stanza because it does not understand some of the stanzas that we are going to use.
As the plugin is designed we can not hook in and intercept those packages without modifying the Jabber protocol code. So we have done that - still hoping to find a better solution later on.

Voicenode object:
We have node started to integrate the voicenode "object" (typedef struct) that we have had in mind for some time. This is a container which should hold the needed information when parsing/generating stanzas.

Code status resume:
We have now made code that can send a range of different stanzas. We have done a good start on the iq-stanza parser which we will next develop further. We hope to see some ping-pong communication soon...

Aiming for the Gtalk to start with!

Now we have split up the code a bit more. We have now more or less generated correctly formed XML for the GTalk protocol. As for now XMPP must waint until the other protocol is done.
What is missing now is still some parsing and the most important: the feature request and update. As for now we are almost certain that when connecting with your client, it updates your local features on the gtalk.google.com server instead of asking P2P. This is our impression because when we are sending our generated GTALK request we get a "service unavailable feature (error 503)". But when we do it through Jabbin it works fine.. And it is through jabbin we will seach and find out how that is done.

A small coding TODO list has also been commited. Hopefully both of us can use some time before next meeting to look at one or two of these TODOs.

-Over and out...

TADAAAA...

After over 2 weeks of frustration with Make/AutoMake we finally got our plugin compiled with more than one .c file. It was several small problems that all together made this huge problems. No help was found in the Gaim forum in which we are currently loosing faith. The object order when linking our files seemed to be the biggest problem.
We now use a normal Makefile which we wrote ourselves instead of using Gaims black-box-magic makefiles. Still no automake, but it we our going to need that someday, we will look into that again.
Bottom line we can now compile a plugin for Gaim with more than one .c file !!!
We still cant access the jabber protocol plugin functions, which would sometimes be convienient. But as they say in the Gaim forum: "you should not do that .... why would you possible want that!"

Today we have synchronized our files in CVS - yeahhh! - after only a few fixes with CVS and a few conflicts it works like a charm.

We are now trying to get some more understandable/organized code, instead of our first muckup code in one looong file (Gaim style!).

We are working on a log file and today we got a JID helper object ready. Besides this some heavy work with implementing protocol will soon arrive...

Make / Automake..

*GRRRRR* we have soon used more than a week to get automake or/and make to work properly inside Gaim and make it compile and link a proper *.so file. And when we finally had done that, it did not work inside gaim. Its very easy to make a plugin in gaim if you only are using a single *.c file and using standard stuff, but if you are not, your basically fucked. Still looking for a simple plugin that does that and does not use automake. Ohh by the way our CVS is up and running again, yeah! :-)