Friday 20 April 2007

¡Propuesta aceptada en GSoC 07!

La propuesta de proyecto que envié al Google Summer of Code 2007 ha sido aceptada.

Eso significa que este verano (desde junio hasta agosto incluidos) trabajaré en dicho proyecto y seré convenientemente remunerado. O sea, que me pagan por trabajar: 4500 USD, al cambio unos 3300€, antes de impuestos.

El proyecto consiste principalmente en implementar Extended Stanza Addressing en Ejabberd. Lo primero es un protocolo que permite enviar el mismo 'stanza' a mucha gente y lo segundo es un servidor de mensajería instantánea Jabber/XMPP.

Tuesday 17 April 2007

What we expect from a GSoC student

I found some recommendations for GSoC developers, which may seem obvious, but are quite useful:

What we expect

* CODE:
- Clean (see CodingStyle).
- Working (try to do small changes, step by step, returning to a working state as often as possible).
- Tested (setup a local test wiki, write unit tests, ...).

* DOCS:
- For developers (e.g. docstrings)
- For users (where appropriate - e.g. as CHANGES entries or Help* wiki pages).

* Regular communication:
- Stay online on #moin-dev.
- Talk about your plans and what you do.
- Ask for help if you are blocked.

* Regular work:
- Citing Google: "your main activity for the summer".
- There must be at least 1 push to your public repo for each day you worked on your project (try to do clean commits, 1 commit per feature / per sub task).

Sunday 15 April 2007

Project Description

Title: Implement XEP-33 Extended Stanza Addressing and other XEPs on ejabberd

Organization: XMPP Standards Foundation

Student: Bernardo Antonio de la Ossa Pérez

Mentor: Mickaël Rémond

Abstract:

I propose to implement 'XEP-0033 Extended Stanza Addressing' as a component on ejabberd. This protocol aims to reduce traffic between Jabber servers when both of them support the protocol, and the clients send broadcast messages. ejabberd's MUC and PubSub components will be updated to use this protocol.

This protocol is already used on several Jabber servers and clients. Implementing it on ejabberd is an important step on the adoption process.

To allow me to get some experience on XEP-reading and implementation, I also propose to implement (or update) three smaller protocols on ejabberd, namely:
XEP-0133: Service Administration
XEP-0157: Contact Addresses for XMPP Services
XEP-0203: Delayed Delivery

With this project, ejabberd will provide more features and the existing features will be better protocol-compliant. Jabber as a whole will benefit with ejabberd support of extended stanza addressing. And finally, I'll get valuable experience on protocol implementation and knowledge on XMPP internals.

Detailed description:

The main purpose of this proposal is to write a module for ejabberd that implements 'XEP-0033 Extended Stanza Addressing' as a component. This XEP can reduce traffic on certain situations, as it allows Jabber entities to specify several recipients on a single XMPP message. Instead of sending a stanza for each user, a single stanza can be sent specifying all the destination addresses.

The MUC and PubSub components included on ejabberd will be updated to support Extended Stanza Addressing. Optimization of bandwidth for MUC is one of the main arguments used against MUC usage over IRC. Hence, this proposal will help spread MUC and thus XMPP use.

This extension requires implementation both on client and servers. Some Open Source programs already implement it: OpenFire server and Psi 0.11 client. Several big public and federated Jabber servers use ejabberd (including jabber.org and jabber.ru). Hence, I expect the addition of this XEP to ejabberd will provide a noticeable reduction on general bandwidth consumption and will incentive other client and servers developers to support it.

By using Epeios, this ejabberd component could be ran with any Jabber server, for example jabberd14 or jabberd2.

The second part of my proposal is to finish the implementation of three more XEPs, which are already partially implemented, but based on early versions of those XEPs, or even before the related XEPs were written.

The protocols I've selected for this part are:
XEP-0133: Service Administration
XEP-0157: Contact Addresses for XMPP Services
XEP-0203: Delayed Delivery
I'll now comment them in more detail.

ejabberd already implements some service administration commands. However, they are direct migration from a very early administration protocol written by Alexey Shchepin back in 2003. My task is to verify that the current implementation adheres to the protocol, and add the remaining commands. On the client part, this protocol requires XEP-04 data forms and XEP-50 ad-hoc commands, which are already implemented on several Jabber clients, including Psi 0.11, Gajim, and Tkabber.

Regarding 'XEP-0157: Contact Addresses for XMPP Services', this is a very small protocol. I'll use it to get some experience in XEP-reading before I focus on the larger parts of my proposal.

Finally, ejabberd is said to implement 'XEP-0091: Delayed Delivery'. My task on this respect is to update the current implementation to XEP-0203. This should be the next step on my learning phase.

Benefits to Community:

My proposal consists on implementing or updating some useful protocols on ejabberd, a widely deployed and used Jabber server. This proposal helps to reduce the bandwidth consumption both on the local Jabber server and the remote one. Its integration into the MUC component will benefit it over IRC.

Additionally, this component will be pluggable to other Jabber servers like jabberd14 and jabberd2.

Deliverables:

During April and May: 'Read, understand and design'
- Read the protocols, understand and clarify all the initial doubts. Will also serve to get contact with my mentor, the XEP author, the standard mailing list and maybe other implementors.
- Initial design of the XEP-33 component.
- Regarding the other smaller XEPs: check which parts of them are already implemented, and whether they require an update.
At the end of this preliminary phase I have perfectly understood the four protocols, I know what needs to be done, and how to do it.

First week of June: 'Implement Contact Addresses and Delayed Delivery'
At the end of the week I have finished implementing Contact Addresses, and updated ejabberd implementation of Delayed Delivery. The code is tested and marked as finished.

From second week of June until second week of July: 'Implement Extended Stanza Addressing'
Implement the full component. Test it with other implementations. At the end of this phase, the component should provide full support for the protocol, and be completely debugged and stable.

Third and fourth weeks of July: 'Give additional features'
Once the component is stable, I'll update ejabberd modules mod_muc and mod_pubsub to use XEP-33 whenever possible.
At the end of this phase, the implementation of XEP-33 is finished.

First and second week of August: 'Implement Service Administration'
First, I'll update the existing commands to the protocol. Once all the existing code is acceptable, implement the remaining commands. At the end of this phase the service administration module is marked as finished.

Third week of August:
If I carry all the previous phases on time, I have a full week to write developer documents. In them I'd describe the API, and how to use it of the ejabberd ad-hoc commands and data forms implementation.

When Summer of Code ends, I hope my work is reviewed and included on mainstream ejabberd. Of course, I'll be available to fix any bugs that may be found on the future.

Open Source experience:

A summary of my involvement in Jabber projects:

Cofounder of the spanish Jabber site jabberes.org, coadministrator of the Jabber server, Drupal administrator, content writer (since Sep 2003)

Involved in Tkabber since Dec 2003: Drupal administrator, tutorial writer, bug reporter, spanish translator, packager of Tkabber-Pack and Tkabber-Starpack.

Involved in ejabberd since Oct 2004: Drupal administrator, tutorial writer, code contributions, and technical assistance on ejabberd's web forum, mailing list and chatroom.

I was once contracted to develop a small module, later published as GPL [3]. My contractor was so happy with the service that payed me a small plus over the initially negotiated amount.

Why do I want to work on this particular project?

I've written several modules or patches for ejabberd since 2004. However, all of them focus on making the administration tasks easier and are not XMPP-related at all. Examples are: logging (messages, chatrooms to HTML and XML), new means of administration (XML-RPC, command line), automated password recovery, statistics gathering...

Until now I've avoided protocol implementation. With this proposal I'll get valuable knowledge and experience on this subject. So, after this project I will be able to contribute not only on interface tasks, but also protocol ones both as ejabberd core code and external components that are usable by any Jabber server.

I don't plan to get employment, class-taking, or any other task that may conflict with this project.

Education:

I obtained BEng on Technical Engineering in System Data Processing at the School of Computer Science at the Polytechnic University of Valencia (Sep 1997 - July 2000). Later followed my studies and obtained the M. Sc. on Computer Science Engineering at the Faculty of Computer Science at the same university (Sep 2000 - July 2003).

Currently I'm half-way on my Ph. D. thesis work on Computer Science on the Department of Systems Data Processing and Computers at the same university. My main research interest is web prefetching techniques. I've developed a complete environment to test and benchmark such techniques in real-world circumstances. This environment is written in Erlang, is highly parametrizable, provides many types of performance statistics and can be used on real scenarios.

I've published several papers related to web architecture and web prefetching.

[1] http://ejabberd.jabber.ru/mod_muc_log
[2] http://ejabberd.jabber.ru/mod_ctlextra
[3] http://ejabberd.jabber.ru/mod_muc_log_xml

Friday 13 April 2007

Proposal accepted at GSoC 07!

So, my proposal was accepted at Google Summer of Code 2007.

During this summer I will implement Extended Stanza Adressing on ejabberd. Since I don't have experience on protocol implementation, I will first experiment implementing/updating smaller protocols, like Delayed Delivery and Contact Addresses for XMPP Services. Finally, if I have enought time at the end of summer, I'll update the current implementation of Service Administration.

With all this work I will not only add some features to a widely used Jabber server, but also get more knowledge of XMPP internals, I'll get more involved on the XSF, and will experiment on Erlang and ejabberd coding.

Extended Stanza Addressing does not only reduce bandwidth usage on the local Jabber server, but also on the destination servers. So adding support for this to ejabberd will benefit the wide federated XMPP network. Or something like that... ;)

The posts related to this project will have gsoc tag, and this is the gsoc RSS feed.