HanzZ

New name and accepted patches

As the headline says, Jabbim transport has a new name. It’s now called Spectrum (according to spectrum of networks it supports and the name also refers to purple color, because we’re using libpurple). I want to also thanks to Florian Thießen from Thiessen IM, because he became the first sponsor of my project. He bought us spectrum.im domain and I’m happy we have also the person who (I hope) will develop the website.

Last few days I was working on my Gloox patches about filetransfer support in order to get them accepted to Gloox svn repository and I’m really happy Jakob pushed them to Gloox-1.0 branch, so the transport will work with Gloox-1.0, which will be released soon.  I want to also thanks to Darkrain42 (Pidgin developer) who helped me a lot with my Abstract-blist-saving patch, which is now in libpurple’s Monotone repository. Thanks to this patch, every UI can now decide how to save Buddy list (It can be stored in MySQL or for example in SQLite). I will write MySQL backend for transport based on this patch in the future, but now I’m working on better filetransfer support.

In order to allow filetransfer straight from XMPP to for example ICQ, I’ve started with new libpurple patch. Actualy, the patch should be done now, but I have to test it, so I’m rewriting filetransfer code in transport now. I hope It will be done in the end of weekend.

Looking for a name

I want to buy domain for my project and also start with building first testing packages, so I’m looking for better project name . The name should be somehow associated with libpurple (that’s the library which transport uses to connect to all networks it supports). It doesn’t mean you have to name it “purple something”, but it would be cool to name it according to something purple (for example eggplant) . Also, the idea of “transporting” is important. The name should somehow express that this software is Jabber Transport (so It can for example refer to some mythological gateway, bridge…). Also there is need to have availabla domain name and don’t have any trademark collisions (so try to use google to search the name first)

So far, my friends suggested me these names:

1. Bifrost – Why? Article on wikipedia. I think with the use of this ASCII version, it’s not so bad name, but it’s not “killer name” and on the first look there is no association with transport or purple .

2. Purpleation – purple + transportation. I think idea is good, but for me it’s hard to read it because of these vowels in the middle.

If you want to help me and you have some ideas, please leave a comment.

Configuration improvement

I’m trying to make transport more user friendly for admins so I’ve (together with Johnny) added comments to variables in config file and I’ve also added lot of configuration options for features which were hardcoded. Transport can be now installed by “make install” command. Default installation prefix is “/usr/local/” and it can be changed for example to “/usr” by “cmak e . -DCMAKE_PREFIX_PATH=/usr” command.

One of the hardcoded features we’re using on Jabbim.cz servers is VIP users support. This feature allows transport admin to divide users into two groups and set different transport features for each group (for example you can disable filetransfer for normal users, because of low server bandwith or *just* because… and VIP users can have this feature enabled). List of VIP users is stored in MySQL table called `vips` and it’s up to server admin to write some interface to add/remove them.

You can also for example set transport to be enabled only for VIP users (this allows you to use whitelist to define transport users). All these options are well documented in config file.

I’m also preparing to make testing package for Ubuntu (unfortunatelly with gloox linked statically).

Filetransfer is working again

Good news everyone! Last few days I was working on the Gloox patch which allows transports to send/receive files. Without this patch, Gloox can send/receive file only from/for Jabber ID which is used for connection to Jabber server (In my case it’s something like icq.jabber.cz). My patch allows to define Jabber ID which will be used as file sender/receiver (so it’s for example 123456789@icq.jabber.cz). I hope Jakob (Gloox library maintainer) will commit this patch to gloox-trunk when he arrives from holiday. Thanks to this patch filetransfer with ICQ should work again and I can start testing filetransfer support for different networks.

Another fixed problem is related to building. Lot of include directories were hardcoded in CMakeLists.txt. I’ve rewrited  CMake build system today and it should compile on every system without any need of manual change. In the near future I plan to add “make install” support, because there are lots of people who want to test the transport during Summer of Code.

I’ve also added support for AIM and I’ve tested it with Nolan, so It should work well .

Internal changes

I’ve  found out that my previous changes related to better IRC support are useful just only for IRC, so I’ve moved them to IRCProtocol class. I had to create new Signals functions to do that. Protocol class can now handle presences and can set its own ProtocolData for connected user (for User class). I want to move more functions, which dependent on concrete protocol, to protocol class instead of executing them always. This will allow to execute only functions which are important for the current protocol, so the the transport will be faster and also the code will look better . It will be also more easier to add new protocol support, because you will have to implement only Protocol class and you won’t need to change anything in the transport core.

I’ve also implemented PURPLE_TYPE_STRING “/transport settings” and the first settings key which use it is “nickserv”. You can set your NickServ password for IRC network there and you will be then automatically identified on connect.

Another new feature could be Private Messages support in IRC. It’s currently in early stage of development and it works only if you start the conversation (no the remote user).

Better IRC support

There was an annoying limitation when you used IRC network with Jabbim Transport. You could connect to only one network from one JID. I’ve fixed it today . Registration is now disabled and you are automatically connected to IRC network when you join for example room #channel%irc.freenode.net@irc.jabbim.cz (btw, It would be cool to have something like Gateway Interaction for rooms, to generate Jabber ID from channel name…). As you can see, the username part of JID is diveded into channel name and server hostname.

The transport just now supports only networks which use standard ports and have no password set. If you join another channel on the same network, the old connection will be used. If you join the channel on different network, new connection (PurpleAccount) will be created. If you disconnect from all channels, the connection is closed and the PurpleAccount is deleted.

I plan to add Ad-Hoc command and PurpleCmd (probably something like “/transport nickserver <name> <password>”) for people who want to identify themselves automatically with NickServ.

New protocols supported

This will be one of the shorter news. Because I’m finishing the first part of my Summer of Code work (It was on plan to implement buddy list managment and to support Ad-Hoc Commands), I’ve added support for SIMPLE, Yahoo, QQ and MySpace network.

I’ve also fixed bugs in situation, when transport crashes (yes, sometimes it happens ) and it’s restarted and users don’t know about it (Transport can’t send unavailable presence to all registered users on start, because that will flood the server). So if the user tries to send message to some transport contact, he will be reconnected and the message will be resent after reconnect.

Support for more resources

With Jabber you can use more clients to login to your Jabber account. Every connected client has his own resource string, which allows service to make a difference between them. Resources weren’t supported by transport until today .

In the older versions, the client features were handled only for the first client which established connection. This brought a serious problem. If user connected from client which doesn’t support for example Roster Item Exchange, this feature was disabled for whole session. This change fixes it and every resource has now its own features list. It depends on resource priority which one will be used.

There is also change in message handling. If you are connected from Psi and Gajim and you start chatting with John from Psi, his responses will be sent to Psi even the Psi has lower priority. If you logout Psi, messages from John will be sent to bare JID (It means JID without resource) and it’s up to server to choose proper client. If you write him from Gajim, responses will be sent to Gajim. If somebody from legacy network starts the conversation with you, the message will be sent also to bare JID.

Another smaller change is that transport supports VCard caching. This is useful for networks like Facebook where the VCard is not changed so often. It saves bandwith and CPU time.

XMPP protocol support

I was thinking what’s the best way how to test purple_request_fields function and today I’ve found out that Jabber protocol uses them a lot, so XMPP is now also supported. I had to change the way how the usernames are handled, because Jabber uses Jabber IDs (so for example if you want to send message to user with JID hanzz@njs.netlab.cz, you should use hanzz%njs.netlab.cz@transport.jabbim.cz). However transport supports XEP-100: Gateway Interaction so if your client supports it too, you just type JID of user you want to write to and transport will generate modified JID for you.

PURPLE_REQUEST_FIELDS in Psi

I’ve also tested and fixed XHTML-IM. Formatted messages are now send only if it’s necessary.

XHTML-IM in Psi

Data Forms and Ad-Hoc commands

Yesterday I had to go to Brno to sign some forms related to my future university education, so I had no time for work. Fortunately, today I’ve made some important changes and added some features.

The first change is the use of Data Forms in In-Band Registration. The main reason why I’ve decided to use data forms there is that user needs to specify server for Sametime protocol (for example) and there is not another way how to allow him to do it. At the start, I wanted to use only Data Forms, but I’ve found Psi sill doesn’t support them (well, you also can’t unregister transport in Psi, but that’s another problem…) so the transport sends also the older registration form.

Transport now resends PURPLE_REQUEST_FIELDS. This gives better support of Ad-Hoc Commands and mainly of Jabber Search, because lots of protocols are using purple_request_fields to get search string. There is now only one purple request (PURPLE_REQUEST_CHOICE) which has to be implemented to have fully supported Ad-Hoc Commands.

There is still PURPLE_REQUEST_MESSAGE hanler missing, but there is no chance to get it work with with 2.x libpurple branch, because PurpleRequestUiOps has to be changed (Problem is the transport doesn’t know which PuprleAccount generated the request so it doesn’t know where to resend it). This kind of changes could be, according to Deryni, done in libpurple 3.x branch.