Version 0.2.0 has been released just one month after version 0.1.0 and four months after development began. With currently nearly one month between a release and the next we have a good release frequency which is fairly important for a project, especially for one which focuses on ease of prototyping new features in and a protocol around it like XMPP with is evolving pretty fast.
With consent of all the other developers, Waqas and my humble self, Matt dictated the use of Lua for the server which has quite some advantages.
Since it's an interpreted language you don't have to wait for building to test some changes you made or don't need stuff like autoconf to build your project cross-platform. However we have some binary modules for encryption and more low-level stuff.
The resulting server is pretty fast, already implements quite some XEPs while not being a memory beast like eJabberd. Not to forget the nice side affect of using Lua as implementation environment which is that you can easily add new protocols to it and test them. This should help us to push the interesting and important XEPs server side so that the client developers get in charge to implement them on their side.
here a short and long awaited update on my Google Summer of Code work. I've been finishing the update of libpurple's Entity Capabilities implementation to the latest version and added a bit functionality so that 3rd-party plugins for Pidgin can query for some contact's capabilities or adding capabilities to Pidgin's feature list which they implement. It's been tested and seems to work. Thanks to Arne König for testing all this and giving useful feedback.
During the last weeks I've added TXT record lookup to libpurple's asynchronous DNS lookup system and make libpurple automatically query for Alternate Connection Methods for XMPP. The end user won't notice much of the underlying mechanics but if she/he is behind some firewall with HTTP proxy and the XMPP service administrator has setup the right records and services libpurple will automatically use BOSH to login and everything will be nice.
Onto new business. I've started implementing a HTTP 1.1 stack which is nearly finished. I've already started implementing BOSH which is based on this new HTTP stack. The great thing about it is that I use Safa Sofuoğlu's Google Summer of Code project, which is about improving OpenFire's BOSH support, for testing. So if I implement according the spec and something doesn't work I can directly report the errors, discuss them and get them fixed quite fast. The best of all will be a XMPP server supporting latest version, version 1.6, of BOSH in form of a connection manager part in OpenFire and a client supporting the latest BOSH.
The next week I'll try to get BOSH at least working and do some debugging and cleaning here and there. If I don't get it finished till GSoC deadline I'll finish it later on.
Cheers and happy coding,
Here a long overdue and promised update on my work on libpurple's XMPP protocol plugin.
Currently I'm finishing support for XEP-0115 version 1.5 in the protocol plugin. I've decided to only support latest version of the XEP because it's most secure. However, what does this mean exactly?
Well, former caps worked so you give a version string and so called short names with your presence stanzas. Though shortnames are really obsolete and we already have a registry for features identified by their namespace and the former version of the protocol didn't provide any amount of security. One could tell you that it's Psi or Tkabber and send a whole different feature set and all clients with that version would be associated with the wrong feature set of the poisoned cache.
Version 1.5 doesn't have these flaws. Whether your contact has a client distributing its capabilities using SHA-1 or MD5 hash, both are supported by the future libpurple. Sadly for contacts having clients not supporting caps it will simply mean a bit more disco requests. For contacts using clients supporting latest version everything will go smoothly and as soon as their hash is confirmed by own recalculation it's added to the own cache.
In the end Entity Capabilities pave the way for painless and user-friendly modern instant messaging features like voice and video over IP, using Jingle, and gaming applications. In the end libpurple based clients will soon join the row of Entity Capabilities supporting clients, which currently is already supported by the latest versions of Gajim and Tkabber.
Next on the list after finishing caps support. A little bit of ad-hoc support cleanup and after that a BOSH implementation for libpurple.
Since XMPP is (becomming) the biggest player from all the instant messaging protocols out there, there are a lot Google Summer of Code™ projects in the XMPP field this year. BOSH, the highly discussed dream team for connecting to XMPP from mobile or other limited network environments, is covered by a lot projects this year. My GSoC project is, not only, about adding BOSH support to libpurple, the C instant messaging library which powers desktop clients like Pidgin and Adium and web clients like Meebo. libpurple doesn’t only cover nearly any proprietary instant messaging protocol but also some open protocols like IRC, SILC and of course XMPP. For XMPP, as the (future) major instant messaging protocol, it’s most important that XEPs get implemented, coded and used in real life. There is a huge number of XEPs which aren’t implemented and may never be, who knows. I will implement BOSH from the beginning since there is no codebase in libpurple in the BOSH field and just contacted Safa Sofuoğlu, a GSoC student for the XSF mentoring organization, who updates Openfire’s BOSH implementation. We plan to test our implementations of the two XEPs, XEP-0124 and XEP-0206, against each other since he’ll write a server side implementation and I’m writing a client side implementation.
Our aim is to have not just working and good performing implementation but moreover implementations according to the two XMPP Enhancement Proposals. I’m looking forward to the inter-project collaboration.
Cheers and good luck to all Google Summer of Code™ students,
Here I present some charts on XEPs, XMPP Enhancement Proposals, and their development. You can see, most XEPs are either in Experimental or Draft status. The one and only final XEPs are currently:
- XEP-0077: In-Band Registration
- XEP-0030: Service Discovery
- XEP-0009: Jabber-RPC
- XEP-0004: Data Forms
There have been two XEP source files unprocessable in XMPP's repository because of invalid XML and since the reposity only exists since end 2006 no longer history was accessable.
These charts have been generated by OpenOffice.org and some custom python script which worked on XSF's svn repository.
I'm working on a new monitor for XMPP networks, in which I most likely take Jabbermonitor down. The upcoming monitor, called xmppmon, is distributed and flexible.
The whole thing is written in C++ using gloox, the 1.0-alpha. This new version introduces gloox::StanzaExtension which makes extending XMPP with your own custom protocols a job of some minutes.
You are just creating a class which you can use on both sides, for receiving and sending the new protocol. Only three tiny steps need to be done if you have the protocol already in mind.
This is our intended protocol for sending and receiving account infos:
You just need to create some function which converts such data into your internal data structure and vice versa and the XPath string that detects such stanza, in this case: /iq/list[@xmlns='http://ayena.de/protocol/xmppmon#serverlistupdate'].
Since gloox now knows about the XPath string it can automatically detect new incoming stanzas which match the new protocol.You can read about the exact mechanics in the gloox documentation.
While most APIs for C++ make you use some complex code the way gloox does this really elegant.
I'm using this a lot in the new xmppmon which I hopefully get finished during the next days.
Google Summer of Code 2007 has ended yesterday and all students have to put their pencils down but that doesn't stop me from releasing some binary builds for MacOS X and Windows. Here is the promised update.
I've achieved all goals I mentioned in my application but there are still some bugs in the formprovider and formdesigner. So if you find them please post them at issue.ayena.de or contact me.
I've worked mainly on the formprovider since last release; therefore there haven't been any big changes in the designer. It's completely controllable via ad-hoc commands, results are stored either in CSV or XML, you can set time frames when you publish some form to users, upload designed forms via file transfer and even download the results through file transfer.
What's left to do is, well, there are people who like it...DOCUMENTATION. To be more precisely, end-user documentation and tutorials which show how easy the formdesigner is to use and how you can use the formproivder to provide those forms to your users.
|dataformdesignersuite.0.2.dmg||Universal binaries for Intel and PPC Macs||7.88 MB|
|dataformdesignersuite.0.2.zip||Binaries for Win (32-bit)||1.40 MB|
|dataformdesignersuite.0.2.tar.bz2||Source package(You'll need gloox and fltk2!)||188 KB|
First the files and data you need:
- ssl.key (your private key you got through the ICA certification process)
- ssl.crt (your certificate)
- the password you used during the ICA certification process
- sub.class1.xmpp.ca.crt (xmpp.net's ICA cert)
Here the list of things you need to do to get a cert-file which works nice with ejabberd:
- Create a backup of the files listed above if you haven't done it yet.
Decrypt ssl.key file using the following command (You will be asked for the password!):
openssl rsa -in ssl.key -out ssl.keyHere the difference between an encrypted ssl.key and decrypted ssl.key:
-----BEGIN RSA PRIVATE KEY----- Proc-Type: 4,ENCRYPTED DEK-Info: AES-256-CBC,08625FF5291958... LH4pfqaXMm86kaFBXFNsZY8HXkPjmBvBH18V... ... dWiJwyTFzAEHXZh1bLZr1C5560FBlGySh35h... -----END RSA PRIVATE KEY-----
-----BEGIN RSA PRIVATE KEY----- MIIEpAIBAAKCAQEA8wY1jnx5koNqhPKN8UkL... ... NuFEKicDmogtN6ojyIx6+JxxKPE7Cu1ru10G... -----END RSA PRIVATE KEY-----
Now you put them all together. Your cert, your private key and xmpp.net's ICA cert. Use the following command:
cat ssl.crt sub.class1.xmpp.ca.crt ssl.key >> myxmpp.net.crt
The resulting myxmpp.net.crt should look like:
——-BEGIN RSA PRIVATE KEY——–
——-END RSA PRIVATE KEY——–
Now you can simply enable TLS for ejabberd like it is described in its documentation.
It’s important that the resulting file has both, your cert and the xmpp.net ICA cert. This may be different for other XMPP server software.
A lot has changed since the last blog post which is just about one week ago. The designer of the data form designer suite for xmpp is ready for some bug testing so I released an alpha release 0.1.0 of it. Now I'm going to concentrate on the console form provider. So feel free to test it and report bugs under my JID. At the bottom of the page there are downloads for the sources of the designer and prebuild binaries for windows.
Here is a small screencast which shows nearly all the forms which are supported by the designer and how to change access control. Just click on the image below.
Here are two screenshots which show the form you just saw in the screencast displayed by Psi and Tkabber. I created the form with the designer and saved my work. Then I've just opened the XML file and copied the form XML into the XML console of my jabber client. Later you'll upload the XML form file from the designer just to the data form provider of this suite and this provider will then send the form on-demand out to the users and store the results.
|formdesigner-0.1.0-src.7z||02abb199 c93d0447 da12d9da fcdaa363||bb341326 67a03b18 9343cf4b bac3945b 82ea4541||251.45 KB|
|formdesigner-0.1.0-src.zip||377c587d f8b0c36a 8a21e44f ea58215b||d6fa9440 d3560917 cb468ee6 ae9acf6f cd6f5a8e||342.78 KB|
|formdesigner-0.1.0-win.7z||5ee24882 6c621c18 078bafa0 c806b16a||890343ed a9fb0173 d4812802 1f736f64 79c9b839||692.78 KB|
|formdesigner-0.1.0-win.zip||cbafda9f d158e14c 0e4aaba5 81df12b8||3aa64a64 c81c8c7f f9a654c1 c0790943 6be12bce||1.08 MB|
After clearing some issues about jid-single and jid-multi field type in XEP-0004 I've just started to implement these last field types which were missing last week.
I've also send in a patch for which makes fltk::ToggleItem and fltk::RadioItem work in fltk::Browser and fltk::MultiBrowser. All other field types are now implemented. Source code documentation which is real-time synchronised with project's repository is available at doc.ayena.de.