Extended Conversation

Hey everyone!

Less than 3 weeks left until the XMPP Summit #8 comes to Brussels.

This year, we’ve got something new! Nokia has generously offered to sponsor a mobile XMPP developer challenge.

What does that mean?

Starting from NOW, you can start writing a mobile application for ANY Nokia platform (Maemo / S60v3 / S60v5 …).

The requirements are:

• The program must be FREELY available; OpenSource is preferred.
• The application needs to be demoed on a Nokia Phone (we have demo devices on location) on the XMPP Summit (Monday). If you are not attending the Summit, find someone who is, and can demo / explain the app, and collect the prize.
• Limit of 1 application per attendee.
• Substantially new code, as decreed on the day by the judges. (If you have questions, the judges will give guidance, but the final decision will be made on the day)
• Judges aren’t eligible.
• And of course: The application needs to use XMPP in some way.

The judges are: Jack Moffitt (XSF Board Chairman); Kevin Smith (XSF Council Chairman); Kristian Luoma (Nokia)

So what can I win?

We have one Nokia N900 generously sponsored by Nokia which the judges will hand over to the best application.

We will also have a second prize, whose winner is chosen by all the attendees (participants excluded). This prize consists of 2 XMPP books (XMPP: The Definitive Guide; Professional XMPP Programming with Javascript and Jquery) and an official XMPP T-Shirt.

So, open up those text editors and start coding, and good luck!

It’s well-known that XMPP technologies emerged from the open-source server project first released by Jeremie Miller in 1999, as well as the combined software/operator community that grew up around the server.

In the early days, “Jabber” meant many things: Jer’s server, the protocol used between clients and servers, the server network, the community in general, even a company called Jabber.com (then Jabber Inc., purchased by Cisco Systems in late 2008). Over time we have worked to disambiguate the terms. Thus Jer’s server was renamed jabberd and the protocol was renamed XMPP.

However, the relationship between the jabber.org and xmpp.org domains has remained a bit nebulous. Several years ago, the Board of Directors of the XMPP Standards Foundation clarified the matter by stating that the jabber.org domain was a community effort hosted on XSF machines but operationally independent of the XSF. That clarification was never formally announced, but the decision was recently re-affirmed by the current Board so now seems like an appropriate time to make the distinction more public.

The basic division of responsibilities is this: the XSF focuses on the “rough consensus” part of “rough consensus and running code” by defining the core protocols used by the entire XMPP community, as published at the xmpp.org website; by contrast, the Jabber.org team focuses on the “running code” part by offering a popular, XMPP-based, real-time communications service. This focus was incorporated into the recent redesign of the jabber.org website (which now is dedicated to information about the jabber.org IM service), and has long been evident at the xmpp.org website as well.

Now you know!

–stpeter

The XMPP Standards Foundation has helped support a number of open-source projects through Google’s Summer of Code program over the years. Although the XSF is not participating in the Google Summer of Code this year, a number of XMPP-related projects have been accepted by other mentoring organizations…

On the JabberFr forums, “Misc” posted the full list:

• Pidgin:
  • XMPP – libpurple transport, allowing servers to offer gateways to all the IM networks that Pidgin (or Adium) supports
  • Privacy Rewrite, giving users powerful controls over “XMPP firewalling”
  • Telepathy prpl, integrating Pidgin’s powerful Purple library with the GNOME Instant Messaging and Presence framework
• Apache Foundation:
  • Extend the Vysper XMPP Server/Client with the publish-subscribe XEP (XEP-060)
• Python Foundation:
  • Gajim: Whiteboard Implementation
  • Adding support for server-side history and roster versioning in Gajim
• Gnome :
  • GNOME-Games + Telepathy: Play GNOME-Sudoku with your IM contacts
  • Implement Music Sharing in Banshee using the Telepathy API
• KDE :
  • VoIP client for KDE (revive KCall)
  • KDE – Conversation Logging Framework
  • Turn Kopete chat window into a library
• Maemo :
  • IM Client For Canola Using Python-purple

At the XSF, we’re tremendously excited to see so much implementation of cutting edge technologies in so many widespread projects. It’s a testement to the innovative nature of the XMPP community, and we’re looking forward to seeing – and using – the results.

Article by Misc, translated by Nicolas Vérité, edited by Dave Cridland.

Reported by Peter Saint-Andre

Back in March, we decided to hold an informal “Monthly XMPP Meeting” among developers in our community. Here is a brief report on the second such meeting, held today (April 14) in the jdev@conference.jabber.org chatroom (the archived discussion log is here).

Here are some of the topics we discussed…

1. Last Call for XEP-0232: Software Information

   The points raised included:

   • Is this a misuse of service discovery?
   • Will this make entity capability caches less useful because they will
     be too large to search easily?
   • Does it make more sense to publish this information via the Personal Eventing Protocol using the old software version format?

   The XMPP Council will vote on XEP-0232 at its next meeting (April 22). More feedback is welcome before then on the standards@xmpp.org mailing list.

2. Last Call for XEP-0237: Roster Versioning

   There is general agreement that this proposed modification to the core XMPP roster management protocol is in good shape. There are still a few edge cases to figure out, especially the empty roster case.

3. Last Calls for the core Jingle specs

   No real discussion here. Most people seemed to think that these are ready for advancement to Draft in the XSF’s standard process.

4. Pubsub/PEP implementations

   Consensus that we need more interop testing among implementation such as ejabberd, idavoll, Openfire, and Tigase. Perhaps we will make this a focus at the next XMPP Summit.

5. XEP-0198: Stream Management

   People like this because it will improve the reliability of communications across the network. Now we need to go forth and implement.

6. Bidirectional server-to-server connections

   As defined in RFC 3920, XMPP requires two TCP connections for each server-to-server (“s2s”) link. This is sub-optimal. We decided that we need to hold a dedicated discussion session about s2s fixes and improvements (server dialback, multiplexing domains over a given stream, etc.). We agreed to make that the focus of the next Monthly XMPP Meeting, tentatively scheduled for May 5 (add it to your calendar here).

My impression is that it is quite valuable to hold these meetings. I especially found it helpful to have a more general community discussion about XMPP Extension Protocols that are currently in Last Call or under heavy development, because it gives people a chance to talk about them in real time rather than only on the standards@xmpp.org mailing list. So expect us to keep holding this kind of online meeting over the coming months.