Difference between revisions of "Summer of Code 2007"

From XMPP WIKI
Jump to navigation Jump to search
m
 
(23 intermediate revisions by 5 users not shown)
Line 1: Line 1:
The [http://www.xmpp.org/ XMPP Standards Foundation] (formerly the Jabber Software Foundation) will once again [http://code.google.com/soc/xmpp/about.html participate] in Google's [http://code.google.com/soc/ Summer of Code] project for 2007.  
The [http://xmpp.org/ XMPP Standards Foundation] (formerly the Jabber Software Foundation) will once again [http://code.google.com/soc/xmpp/about.html participate] in Google's [http://code.google.com/soc/ Summer of Code] project for 2007.


XMPP is the Extensible Messaging and Presence Protocol, an XML wire protocol for real-time communication that emerged from the [http://www.jabber.org/ Jabber] open-source community. Although our community is centered around open standards instead of a single open-source codebase, we still have a strong commitment to open code and there are many free and open-source projects in our community.
XMPP is the Extensible Messaging and Presence Protocol, an XML wire protocol for real-time communication that emerged from the [http://www.jabber.org/ Jabber] open-source community. Although our community is centered around open standards instead of a single open-source codebase, we still have a strong commitment to open code and there are many free and open-source projects in our community.


This year we will do things a little differently. In particular, we have recruited mentors ahead of time and potential mentors have defined project ideas that students can work on. This is similar to a "Request for Proposal" process, with the mentors being the people who defined the RFPs and who will "interview" the student whose proposals are of interest.
This year we will do things a little differently. In particular, we have recruited mentors ahead of time and potential mentors have defined project ideas that students can work on. This is similar to a "Request for Proposal" process, with the mentors being the people who defined the RFPs and who will "interview" the student whose proposals are of interest.


In general, we are most interested in projects that are relevant to our [http://www.xmpp.org/xsf/roadmap.shtml roadmap]. See below for details.
In general, we are most interested in projects that are relevant to our [http://xmpp.org/xsf/roadmap.shtml roadmap]. See below for details.


= Mentors =
= Mentors =
Line 16: Line 16:
* Chris Mullins - .NET
* Chris Mullins - .NET
* Kevin Smith - C++, clients
* Kevin Smith - C++, clients
* Remko Tronçon - C++, clients
* Remko Tronçon - C++, clients
* Justin Karneges - C++, clients, libraries
* Justin Karneges - C++, clients, libraries
* Alexander Gnauck - .NET, C#, clients, libraries
* Alexander Gnauck - .NET, C#, clients, libraries
Line 23: Line 23:
* Mats Bengtsson - Tcl / C
* Mats Bengtsson - Tcl / C
* Massimiliano Mirra - JavaScript / Mozilla
* Massimiliano Mirra - JavaScript / Mozilla
* Jakob Schröter - C, C++, clients, components, libraries
* Stephan Maka - Ruby


= Roadmap Project Ideas =
= Roadmap Project Ideas =


In general, we are most interested in projects that are relevant to our [http://www.xmpp.org/xsf/roadmap.shtml roadmap]. These include:
In general, we are most interested in projects that are relevant to our [http://xmpp.org/xsf/roadmap.shtml roadmap]. These include:


* Jingle for VoIP etc.
* Jingle for VoIP etc.
Line 38: Line 40:
== Jingle ==
== Jingle ==


Jingle (defined in several specs, start with [http://www.xmpp.org/extensions/xep-0166.html XEP-0166]) is our emerging technology for Voice over IP, video, and other multimedia interactions. Because adding Jingle support is a big project, it probably makes more sense to develop a specific aspect of Jingle support, such as the file transfer content type or a particular transport method. This is client-side only so there are no server projects here. Talk with the maintainers of a client you're interested in about what makes sense here, since some client codebases are farther along than others in Jingle implementation.
Jingle (defined in several specs, start with [http://xmpp.org/extensions/xep-0166.html XEP-0166]) is our emerging technology for Voice over IP, video, and other multimedia interactions. Because adding Jingle support is a big project, it probably makes more sense to develop a specific aspect of Jingle support, such as the file transfer content type or a particular transport method. This is client-side only so there are no server projects here. Talk with the maintainers of a client you're interested in about what makes sense here, since some client codebases are farther along than others in Jingle implementation.


== Certification ==
== Certification ==


We are working on a certification program for 2008 and beyond. This will enable client, server, and library codebases to be certified for various levels of protocol compliance. For that reason we have defined two main compliance levels: [http://www.xmpp.org/extensions/xep-0073.html XMPP Basic] and [http://www.xmpp.org/extensions/xep-0117.html XMPP Intermediate]. These protocol suites will be stable by June 30 2007 for 2008 certification. Bringing an existing codebase up to the Basic or Intermediate level will help those projects achieve compliance and enable us to deploy more standardized clients and servers across the network. Talk with the maintainers of client, server, and library projects to figure out what the "gap" is for your codebase of interest.
We are working on a certification program for 2008 and beyond. This will enable client, server, and library codebases to be certified for various levels of protocol compliance. For that reason we have defined two main compliance levels: [http://xmpp.org/extensions/xep-0073.html XMPP Basic] and [http://xmpp.org/extensions/xep-0117.html XMPP Intermediate]. These protocol suites will be stable by June 30 2007 for 2008 certification. Bringing an existing codebase up to the Basic or Intermediate level will help those projects achieve compliance and enable us to deploy more standardized clients and servers across the network. Talk with the maintainers of client, server, and library projects to figure out what the "gap" is for your codebase of interest.


== Personal Eventing ==
== Personal Eventing ==


Several years ago we defined a robust protocol for generalized "publish-subscribe" (pubsub) functionality. More recently we defined a friendly "subset" or "profile" of pubsub that is suitable for IM networks. This "personal eventing" technology will enable us to deploy fun extended presence and social networking features like user moods ("how are you feeling?") and real-time music feeds ("what are you listening to?").  
Several years ago we defined a robust protocol for generalized "publish-subscribe" (pubsub) functionality. More recently we defined a friendly "subset" or "profile" of pubsub that is suitable for IM networks. This "personal eventing" technology will enable us to deploy fun extended presence and social networking features like user moods ("how are you feeling?") and real-time music feeds ("what are you listening to?").


The personal eventing protocol is defined in [http://www.xmpp.org/extensions/xep-0163.html XEP-0163] and support can be added to both servers and clients. Adding support to a server will involve only the core eventing itself. Adding support to a client will involve eventing as well as event payloads like [http://www.xmpp.org/extensions/xep-0107.html user mood] and [http://www.xmpp.org/extensions/xep-0118.html user tune].
The personal eventing protocol is defined in [http://xmpp.org/extensions/xep-0163.html XEP-0163] and support can be added to both servers and clients. Adding support to a server will involve only the core eventing itself. Adding support to a client will involve eventing as well as event payloads like [http://xmpp.org/extensions/xep-0107.html user mood] and [http://xmpp.org/extensions/xep-0118.html user tune].


== Message Archiving ==
== Message Archiving ==


Traditionally, Jabber clients have archived or logged messages on the local machine of the user. But what if you use a web client, or you switch back and forth between different devices? It would be great to save your messages on the server so that you could retrieve them from anywhere, so we've defined a protocol for doing just that in [http://www.xmpp.org/extensions/xep-0136.html XEP-0136]. A SoC project could add support for message archiving to a client (especially a web client) or a server.
Traditionally, Jabber clients have archived or logged messages on the local machine of the user. But what if you use a web client, or you switch back and forth between different devices? It would be great to save your messages on the server so that you could retrieve them from anywhere, so we've defined a protocol for doing just that in [http://xmpp.org/extensions/xep-0136.html XEP-0136]. A SoC project could add support for message archiving to a client (especially a web client) or a server.


== End-to-End Encryption ==
== End-to-End Encryption ==
Line 60: Line 62:
First, the following two specifications essentially define a session-based model for XMPP communication. Modifying an existing client or library to properly handle stanza sessions would provide a strong basis for end-to-end encryption, enabling hooks into encryption libraries.
First, the following two specifications essentially define a session-based model for XMPP communication. Modifying an existing client or library to properly handle stanza sessions would provide a strong basis for end-to-end encryption, enabling hooks into encryption libraries.


* [http://www.xmpp.org/extensions/xep-0201.html XEP-0201: Best Practices for Message Threads]
* [http://xmpp.org/extensions/xep-0201.html XEP-0201: Best Practices for Message Threads]
* [http://www.xmpp.org/extensions/xep-0155.html XEP-0155: Stanza Session Negotiation]
* [http://xmpp.org/extensions/xep-0155.html XEP-0155: Stanza Session Negotiation]


Second, the following two specifications define methods for the end-to-end encryption itself. It makes sense to implement these specifications in a library so that multiple clients can use the underlying code:
Second, the following two specifications define methods for the end-to-end encryption itself. It makes sense to implement these specifications in a library so that multiple clients can use the underlying code:


* [http://www.xmpp.org/extensions/xep-0200.html XEP-0200: Stanza Encryption]
* [http://xmpp.org/extensions/xep-0200.html XEP-0200: Stanza Encryption]
* [http://www.xmpp.org/extensions/xep-0116.html XEP-0116: Encrypted Session Negotiation]
* [http://xmpp.org/extensions/xep-0116.html XEP-0116: Encrypted Session Negotiation]


= Existing Open-Source Projects =
= Existing Open-Source Projects =


Jabber/XMPP technologies are based on a client-server architecture similar to email (well, but better). Thus the main open-source projects are clients and servers. However there are also lots of code libraries you can contribute to as well. The following sections list some of the more popular projects. There are also complete lists of [http://www.jabber.org/software/clients.shtml clients], [http://www.jabber.org/software/servers.shtml servers], and [http://www.jabber.org/software/libraries.shtml libraries] and the jabber.org website.
Jabber/XMPP technologies are based on a client-server architecture similar to email (well, but better). Thus the main open-source projects are clients and servers. However there are also lots of code libraries you can contribute to as well. The following sections list some of the more popular projects. There are also complete lists of [http://www.jabber.org/software/clients.shtml clients], [http://www.jabber.org/software/servers.shtml servers], and [http://www.jabber.org/software/libraries.shtml libraries] at the jabber.org website.


Given the large number of existing projects, there is plenty of opportunity for fun SoC work. We prefer that you contribute to existing open-source codebases instead of starting a new codebase, since it will be easier to find a mentor, so use the project lists below to find a good fit. If you have questions about an existing codebase, ask the maintainers of that codebase, post to the [http://mail.jabber.org/mailman/listinfo/jdev main developer list], or join our developer chatroom at xmpp:jdev@conference.jabber.org (yes, we have multi-user chat, like IRC but over the Jabber network).
Given the large number of existing projects, there is plenty of opportunity for fun SoC work. We prefer that you contribute to existing open-source codebases instead of starting a new codebase, since it will be easier to find a mentor, so use the project lists below to find a good fit. If you have questions about an existing codebase, ask the maintainers of that codebase, post to the [http://mail.jabber.org/mailman/listinfo/jdev main developer list], or join our developer chatroom at xmpp:jdev@conference.jabber.org (yes, we have multi-user chat, like IRC but over the Jabber network).


== Clients ==
== Clients ==
Line 85: Line 87:
* [http://kopete.kde.org/ Kopete] (KDE)
* [http://kopete.kde.org/ Kopete] (KDE)
* [http://psi-im.org/ Psi] (C++/Qt)
* [http://psi-im.org/ Psi] (C++/Qt)
* [http://sameplace.cc/ SamePlace] (JavaScript/Mozilla)
* [http://www.igniterealtime.org/projects/spark/ Spark] (Java)
* [http://www.igniterealtime.org/projects/spark/ Spark] (Java)


Line 91: Line 94:
== Servers ==
== Servers ==


As noted, Jabber/XMPP technologies use a client-server architecture. There are five main open-source server codebases:
As noted, Jabber/XMPP technologies use a client-server architecture. There are several open-source server codebases:


* [http://www.process-one.net/en/ejabberd/ ejabberd] (Erlang)
* [http://www.process-one.net/en/ejabberd/ ejabberd] (Erlang)
Line 97: Line 100:
* [http://docs.xiaoka.com/jabberd2:start jabberd2] (C)
* [http://docs.xiaoka.com/jabberd2:start jabberd2] (C)
* [http://www.igniterealtime.org/projects/openfire/ Openfire] (Java)
* [http://www.igniterealtime.org/projects/openfire/ Openfire] (Java)
* [http://www.psyced.org/ psyced] (C/LPC)
* [http://www.tigase.org/ Tigase] (Java)
* [http://www.tigase.org/ Tigase] (Java)


Line 119: Line 123:
* [http://twistedmatrix.com/projects/words/ Twisted Words] (Python)
* [http://twistedmatrix.com/projects/words/ Twisted Words] (Python)
* [http://www.igniterealtime.org/projects/xiff/ XIFF] (Flash)
* [http://www.igniterealtime.org/projects/xiff/ XIFF] (Flash)
* [http://dev.hyperstruct.net/xmpp4moz/ xmpp4moz] (JavaScript, Mozilla)
* [http://home.gna.org/xmpp4r/ XMPP4R] (Ruby)
* [http://home.gna.org/xmpp4r/ XMPP4R] (Ruby)
* [http://xmpppy.sourceforge.net/ xmpppy] (Python)
* [http://xmpppy.sourceforge.net/ xmpppy] (Python)
Line 124: Line 129:
Most of the roadmap project ideas described above can be done in any of these libraries, so combine a project idea with a codebase and send in a proposal.
Most of the roadmap project ideas described above can be done in any of these libraries, so combine a project idea with a codebase and send in a proposal.


= Cross-Pollination Projects =
= Cross-Pollination Project Ideas =


There are many opportunities for integrating real-time features like user availability ("presence") and instant messaging into other GSoC projects. Some of these may be more appropriate for other mentoring organizations. Here are some ideas:
There are many opportunities for integrating real-time features like user availability ("presence") and instant messaging into other GSoC projects. Many of these may be more appropriate for other mentoring organizations. Here are some ideas:


* [http://code.google.com/soc/abisource/about.html AbiSource] or [http://code.google.com/soc/ooo/about.html OpenOffice.org] -- Add presence icons to documents so that you can see the availability of document authors and click to chat
* [http://code.google.com/soc/abisource/about.html AbiSource] or [http://code.google.com/soc/ooo/about.html OpenOffice.org] -- Add presence icons to documents so that you can see the availability of document authors and click to chat
* [http://code.google.com/soc/drupal/about.html Drupal], [http://code.google.com/soc/moin/about.html MoinMoin], [http://code.google.com/soc/wikimedia/about.html Wikimedia], [http://code.google.com/soc/xwiki/about.html XWiki], or [http://code.google.com/soc/zope/about.html Zope] -- Add authentication against Jabber IDs and/or closer integration with Jabber addresses as identities, presence icons for Jabber users, real-time change notifications via Jabber (why wait for email?), etc.
* [http://code.google.com/soc/inkscape/about.html Inkscape] -- Building on a 2006 GSoC project, harmonize [http://inkboard.sourceforge.net/ Inkboard] more closely with other Jabber-based whiteboarding systems and protocols.
* [http://code.google.com/soc/internet2/about.html Internet2] -- There is a lot of interest in XMPP technologies among the Internet2 community, ask around in the PIC working group for project ideas.
* [http://code.google.com/soc/mozilla/about.html Mozilla] or [http://code.google.com/soc/squirrel/about.html SquirrelMail] -- Add Jabber presence icons to show if other user is online (via [[Jabber Email Header|Jabber-ID email header]] or other means) and then click to chat or groupchat.
* [http://code.google.com/soc/osaf/about.html Open Source Applications Foundation] -- A good personal information manager needs to have support for real-time communications, so a contribution to OSAF's Chandler project makes a lot of sense (integrated presence and IM, etc.).
* [http://code.google.com/soc/mono/about.html Mono], [http://code.google.com/soc/php/about.html PHP], [http://code.google.com/soc/psf/about.html Python], or [http://code.google.com/soc/ruby/about.html Ruby] -- All of these languages deserve core support for XMPP in order to introduce more real-time features into a wide range of applications. Work on one of the existing .NET, PHP, Python, or Ruby libraries (e.g., XMPP Basic compliance) would speed that process along.
* [http://code.google.com/soc/sipcomm/about.html SIP Communicator] -- Closer integration between SIP and XMPP would be quite beneficial for interoperability. Bringing SIP Communicator up to compliance with the XMPP Basic or XMPP Intermediate protocol suite would help quite a bit.
* [http://code.google.com/soc/svn/about.html Subversion] -- Add support for real-time change notifications via Jabber.
* [http://code.google.com/soc/ubuntu/about.html Ubuntu] -- There is some work on integration of Jabber messaging into Ubuntu, ask around in the Ubuntu community.
* [http://code.google.com/soc/wordpress/about.html Wordpress] -- Add better integration with Jabber addresses, inclusion of real-time user information in blog pages (e.g., current mood and tune), verification of comments via "ping" back to Jabber user (XEP-0070), real-time change notifications via Jabber, support for Atom Over XMPP via publish-subscribe, etc.


* [http://code.google.com/soc/drupal/about.html Drupal], [http://code.google.com/soc/moin/about.html MoinMoin], [http://code.google.com/soc/wikimedia/about.html Wikimedia], or [http://code.google.com/soc/xwiki/about.html XWiki] -- Add authentication against Jabber IDs and/or closer integration with Jabber addresses as identities, presence icons for Jabber users, real-time change notifications via Jabber (why wait for email?), etc.
= Insert Your Idea Here! =


* [http://code.google.com/soc/inkscape/about.html Inkscape] -- Building on a 2006 GSoC project, harmonize [http://inkboard.sourceforge.net/ Inkboard] more closely with other Jabber-based whiteboarding systems and protocols.
Although we have ideas for projects, your ideas may be better. :) Feel free to come up with your own creative proposal that does not address one of the project ideas listed on this page.


* [http://code.google.com/soc/internet2/about.html Internet2] -- There is a lot of interest in XMPP technologies among the Internet2 community, ask around in the PIC working group for project ideas.
= Other Project Ideas =


* [http://code.google.com/soc/svn/about.html Subversion] -- Add support for real-time change notifications via Jabber
== Igniterealtime.org Project Ideas ==


* [http://code.google.com/soc/ubuntu/about.html Ubuntu] -- There is some work on integration of Jabber messaging into Ubuntu, ask around in the Ubuntu community.
Several projects ideas for the Open Source projects hosted at igniterealtime.org (Openfire, Spark, Smack):


* [http://code.google.com/soc/wordpress/about.html Wordpress] -- Add better integration with Jabber addresses, inclusion of real-time user information in blog pages (e.g., current mood and tune), verification of comments via "ping" back to Jabber user (XEP-0070), real-time change notifications via Jabber, support for Atom Over XMPP via publish-subscribe, etc.
<pre>  * Asterisk-IM: Asterisk and Openfire Integration
 
  * Link-Local Messaging (XEP-0174) support
= Other Project Ideas =
  * File transfers for gateways
  * Jingle Voicemail
  * Group Chat for Gateways
  * G722 Codec for JMF</pre>
For more details, visit the [http://wiki.igniterealtime.org/display/WILDFIRE/Summer+of+Code+2007 ignite project ideas page].


== Coccinella: Jingle file transfer ==
== Coccinella: Jingle file transfer ==
Line 151: Line 170:
=== Project motivation ===
=== Project motivation ===


Transporting files from one user to another is plagued by NATs and firewalls. In ancient times a standard Tcp connection was all that was needed. Instead various application level protocols have been implemented on top of Udp which handles NATs much better. This "reinventing the wheel" by having to reimplement a kind of pseudo Tcp stack on top of Udp is a very unfortunate situation which lacks standardization.
Transporting files from one user to another is plagued by NATs and firewalls. In ancient times a standard Tcp connection was all that was needed. Instead various application level protocols have been implemented on top of Udp which handles NATs much better. This &quot;reinventing the wheel&quot; by having to reimplement a kind of pseudo Tcp stack on top of Udp is a very unfortunate situation which lacks standardization.


=== Implementation ===
=== Implementation ===


This projects aims to use Google gTalks Jingle implementation as a starting point. Ufortunately it is written in C++ and deeply tied into the application notifier system and therefore not reusable as is. Instead the task will be to use the Tcl Udp C code implementation, and essentially use gTalks PseudoTcp class as a wrapper. There are two possible options here: either do a pur Tcl script implementation of the tricks used in PseudoTcp, which I'm not sure is possible, or just translate the C++ class into C code and wrap up the tcludp package to a pseudo tcp (ptcp) command. This should work just like the standard Tcl socket command and should be able to use it transparently.
This projects aims to use Google gTalks Jingle implementation as a starting point. Ufortunately it is written in C++ and deeply tied into the application notifier system and therefore not reusable as is. Instead the task will be to use the Tcl Udp C code implementation, and essentially use gTalks PseudoTcp class as a wrapper. There are two possible options here: either do a pure Tcl script implementation of the tricks used in PseudoTcp, which I'm not sure is possible, or just translate the C++ class into C code and wrap up the tcludp package to a pseudo tcp (ptcp) command. This should work just like the standard Tcl socket command and should be able to use it transparently.


Jingle contains several parts but the actual jingle xmpp protocol stack is already running and used for voip. A limited STUN client has also been implemented in pure Tcl, but some support for the ICE protocol will likely be necessary.
Jingle contains several parts but the actual jingle xmpp protocol stack is already running and used for voip. A limited STUN client has also been implemented in pure Tcl, but some support for the ICE protocol will likely be necessary.
Line 161: Line 180:
=== Relevant XEPs ===
=== Relevant XEPs ===


*[http://www.xmpp.org/extensions/xep-0166.html Jingle]
* [http://xmpp.org/extensions/xep-0166.html Jingle]
*[http://www.xmpp.org/extensions/xep-0176.html Jingle ICE Transport]
* [http://xmpp.org/extensions/xep-0176.html Jingle ICE Transport]
*[http://www.xmpp.org/extensions/xep-0177.html Jingle Raw UDP Transport]
* [http://xmpp.org/extensions/xep-0177.html Jingle Raw UDP Transport]


There seems to be a XEP in the works that actually describes the topmost file transfer protocol.
There seems to be a XEP in the works that actually describes the topmost file transfer protocol.
Line 175: Line 194:
=== Project description ===
=== Project description ===


This project involves the creation of an interface for kids to Coccinella. You need to create a new roster style, the fishy roster style, with an aquarium containing fishes that represents the contacts (like [http://ralphm.net/ ralphm's Jabber Aquarium]). The fishes need to be be animated with [http://www.jabber.org/jeps/jep-0107.html User Mood]. For example, when a contact is happy, the fish will swim quickly in the aquarium with a smile on his face. The graphics will be done in 2D, but when time allows, they can be made in 3D.
This project involves the creation of an interface for kids to Coccinella. You need to create a new roster style, the fishy roster style, with an aquarium containing fishes that represents the contacts (like [http://ralphm.net/ ralphm's Jabber Aquarium]). The fishes need to be be animated with [http://xmpp.org/extensions/xep-0107.html User Mood]. For example, when a contact is happy, the fish will swim quickly in the aquarium with a smile on his face. The graphics will be done in 2D, but when time allows, they can be made in 3D.


The programming tools will be Tcl/Tk and the tkpath graphics extension package [http://tclbitprint.sf.net/] which provides high quality graphics on all platforms. There exists an albeit primitive SVG importer so the actual graphics elements can be obtained from a SVG drawing tool.
The programming tools will be Tcl/Tk and the tkpath graphics extension package [http://tclbitprint.sf.net/ [1]] which provides high quality graphics on all platforms. There exists an albeit primitive SVG importer so the actual graphics elements can be obtained from a SVG drawing tool.


This project will involve mostly new code, and less boring code rewriting.
This project will involve mostly new code, and less boring code rewriting.
Line 183: Line 202:
=== Relevant XEPs ===
=== Relevant XEPs ===


*[http://www.xmpp.org/extensions/xep-0107.html User Mood]
* [http://xmpp.org/extensions/xep-0107.html User Mood]
*[http://www.xmpp.org/extensions/xep-0108.html User Activity]
* [http://xmpp.org/extensions/xep-0108.html User Activity]
*[http://www.xmpp.org/extensions/xep-0163.html Personal Eventing via Pubsub]
* [http://xmpp.org/extensions/xep-0163.html Personal Eventing via Pubsub]


== Gajim: Jingle VOIP ==
== Gajim: Jingle VOIP ==
Line 197: Line 216:
=== Relevant XEPs ===
=== Relevant XEPs ===


*[http://www.xmpp.org/extensions/xep-0166.html Jingle]
* [http://xmpp.org/extensions/xep-0166.html Jingle]
*[http://www.xmpp.org/extensions/xep-0167.html Jingle Audio Content Description Format]
* [http://xmpp.org/extensions/xep-0167.html Jingle Audio Content Description Format]


== xmpp4moz: Shared-over-XMPP Web Applications ==
== xmpp4moz: Shared-over-XMPP Web Applications ==
Line 207: Line 226:
=== Project motivation ===
=== Project motivation ===


On the web, people interact with web applications; in instant messaging, they interact with other people. By bringing XMPP to the browser we can mix the two scenarios and allow people to interact with other people ''on'' web applications. The result is richer forms of interaction (e.g. shared editors, games, whiteboards, ...) that can be deployed to everyone with the ease of web applications, i.e. by just uploading pages to a server and giving away a URL.
On the web, people interact with web applications; in instant messaging, they interact with other people. By bringing XMPP to the browser we can mix the two scenarios and allow people to interact with other people ''on'' web applications. The result is richer forms of interaction (e.g. shared editors, games, whiteboards, ...) that can be deployed to everyone with the ease of web applications, i.e. by just uploading pages to a server and giving away a URL.


=== Implementation ===
=== Implementation ===
Line 220: Line 239:


== Extended addressing support ==
== Extended addressing support ==
[http://www.xmpp.org/extensions/xep-0033.html XEP-0033] is a XMPP extension which can save a lot S2S (Server to Server) traffic and let you easily send messages to more than one contact, even with cc and bcc recipients you used to know from electronic mail. The XEP hasn't changed since 2004 but there are only some implementations at the moment. So your project could be to add support for XEP-0033 to your open source server of choice. If that isn't enough some servers, e.g. eJabberd, have own components for PubSub and MUC so if adding XEP-0033 support to those servers it should be easy for you to add support to the included components too.


== Data Forms Framework ===
[http://xmpp.org/extensions/xep-0033.html XEP-0033] is a XMPP extension which can save a lot S2S (Server to Server) traffic and let you easily send messages to more than one contact, even with cc and bcc recipients you used to know from electronic mail. The XEP hasn't changed since 2004 but there are only some implementations at the moment. So your project could be to add support for XEP-0033 to your open source server of choice. If that isn't enough some servers, e.g. eJabberd, have own components for PubSub and MUC so if adding XEP-0033 support to those servers it should be easy for you to add support to the included components too.
 
== Data Forms Framework ==
 
Build a [http://xmpp.org/extensions/xep-0004.html X-Data] framework consisting of:


Build a [http://www.xmpp.org/extensions/xep-0004.html X-Data] framework consisting of:
* Visual X-Data forms editor
* Visual X-Data forms editor
* application to send forms to entities, analyze and store the submitted results
* application to send forms to entities, analyze and store the submitted results
Line 232: Line 253:


This is how it should work on the client side:
This is how it should work on the client side:
* During installation of the distribution, a Jabber account is registered (or SASL Anonymous is used) and the user will be subscribed to the Publish-Subscribe nodes representing the repositories he is interested in.
* During installation of the distribution, a Jabber account is registered (or SASL Anonymous is used) and the user will be subscribed to the Publish-Subscribe nodes representing the repositories he is interested in.
* When the distribution is started, a daemon is started which is a Jabber client.
* When the distribution is started, a daemon is started which is a Jabber client.
Line 237: Line 259:


This is how it should work on the server side:
This is how it should work on the server side:
* Publish-Subscribe nodes for each package (or each repository?).
* Publish-Subscribe nodes for each package (or each repository?).
* Initially, the system can use an existing repository, and get updates each minute e.g. In a later stage, the system should be notified when a new package is uploaded to the server.
* Initially, the system can use an existing repository, and get updates each minute e.g. In a later stage, the system should be notified when a new package is uploaded to the server.
Line 242: Line 265:


Motivation:
Motivation:
* Increase end-user satisfaction
* Increase end-user satisfaction


Advantages over current pull based systems:
Advantages over current pull based systems:
* safer as you will be notified about updates in real-time
* safer as you will be notified about updates in real-time
* faster and less server load/traffic ([http://osnews.com/story.php/17505/Ubuntu-Feisty-Fawn-Desktop-Linux-Matured you don't have to download 5MB or something like that])
* faster and less server load/traffic ([http://osnews.com/story.php/17505/Ubuntu-Feisty-Fawn-Desktop-Linux-Matured you don't have to download 5MB or something like that])
Line 254: Line 279:


Requirements:
Requirements:
* scalability
* scalability
* easy/transparent
* easy/transparent
* client & server
* client &amp; server
* secure: PGP, SASL, TLS,...
* secure: PGP, SASL, TLS,...


Line 264: Line 290:


Motivation:
Motivation:
* Increase end-user satisfaction regarding their open source system and better feedback for packagers and software projects.
* Increase end-user satisfaction regarding their open source system and better feedback for packagers and software projects.


Line 269: Line 296:


Requirements:
Requirements:
* way to point to the project's Multi-User Chat room (in the package or via the XMPP server?)
* way to point to the project's Multi-User Chat room (in the package or via the XMPP server?)
* way to point to the Jabber ID of the maintainer (in the package or via the XMPP server?)
* way to point to the Jabber ID of the maintainer (in the package or via the XMPP server?)
Line 278: Line 306:


== Tunneling (asynchronous) Web Services for Bioinformatics application over XMPP by supporting Ad-Hoc Commands (XEP-0050) and IO-Object Forms ==
== Tunneling (asynchronous) Web Services for Bioinformatics application over XMPP by supporting Ad-Hoc Commands (XEP-0050) and IO-Object Forms ==
The student's challenge is to write server components and/or client implementations that export/import Web Services for Bioinformatics by making use of [http://www.xmpp.org/extensions/xep-0050.html XEP-0050 - Ad-Hoc Commands] and the yet to be council-voted [http://www.xmpp.org/extensions/inbox/io-object-forms.html IO-Object Forms]. Client implmementations could be developed as Plug-In for the [http://bioclipse.net/ Bioclipse] Bioinformatics IDE that was recently introduced in [http://www.biomedcentral.com/1471-2105/8/59/abstract BMC Bioinformatics]. Web Services for Bioinformatics may base on existing databases or algorithms, for example by routing [http://en.wikipedia.org/wiki/GenBank GenBank entries] through XMPP.
 
The student's challenge is to write server components and/or client implementations that export/import Web Services for Bioinformatics by making use of [http://xmpp.org/extensions/xep-0050.html XEP-0050 - Ad-Hoc Commands] and the yet to be council-voted [http://xmpp.org/extensions/inbox/io-object-forms.html IO-Object Forms]. Client implmementations could be developed as Plug-In for the [http://bioclipse.net/ Bioclipse] Bioinformatics IDE that was recently introduced in [http://www.biomedcentral.com/1471-2105/8/59/abstract BMC Bioinformatics]. Web Services for Bioinformatics may base on existing databases or algorithms, for example by routing [http://en.wikipedia.org/wiki/GenBank GenBank entries] through XMPP.


Mentor: Johannes Wagener
Mentor: Johannes Wagener

Latest revision as of 02:34, 17 December 2020

The XMPP Standards Foundation (formerly the Jabber Software Foundation) will once again participate in Google's Summer of Code project for 2007.

XMPP is the Extensible Messaging and Presence Protocol, an XML wire protocol for real-time communication that emerged from the Jabber open-source community. Although our community is centered around open standards instead of a single open-source codebase, we still have a strong commitment to open code and there are many free and open-source projects in our community.

This year we will do things a little differently. In particular, we have recruited mentors ahead of time and potential mentors have defined project ideas that students can work on. This is similar to a "Request for Proposal" process, with the mentors being the people who defined the RFPs and who will "interview" the student whose proposals are of interest.

In general, we are most interested in projects that are relevant to our roadmap. See below for details.

Mentors

The following people are potential mentors for Jabber/XMPP related projects. The final mentors will depend on which projects are accepted.

  • Ralph Meijer - Python / Twisted, libraries
  • Jacek Konieczny - Python / C++
  • Gaston Dombiak - Java
  • Chris Mullins - .NET
  • Kevin Smith - C++, clients
  • Remko Tronçon - C++, clients
  • Justin Karneges - C++, clients, libraries
  • Alexander Gnauck - .NET, C#, clients, libraries
  • Maciej Niedzielski - C++, clients
  • Johannes Wagener - Web Services, Java, C++, server components, clients, libraries
  • Mats Bengtsson - Tcl / C
  • Massimiliano Mirra - JavaScript / Mozilla
  • Jakob Schröter - C, C++, clients, components, libraries
  • Stephan Maka - Ruby

Roadmap Project Ideas

In general, we are most interested in projects that are relevant to our roadmap. These include:

  • Jingle for VoIP etc.
  • Certification
  • Personal eventing
  • Message archiving
  • End-to-end encryption

Detailed descriptions of these project ideas are provided below.

Jingle

Jingle (defined in several specs, start with XEP-0166) is our emerging technology for Voice over IP, video, and other multimedia interactions. Because adding Jingle support is a big project, it probably makes more sense to develop a specific aspect of Jingle support, such as the file transfer content type or a particular transport method. This is client-side only so there are no server projects here. Talk with the maintainers of a client you're interested in about what makes sense here, since some client codebases are farther along than others in Jingle implementation.

Certification

We are working on a certification program for 2008 and beyond. This will enable client, server, and library codebases to be certified for various levels of protocol compliance. For that reason we have defined two main compliance levels: XMPP Basic and XMPP Intermediate. These protocol suites will be stable by June 30 2007 for 2008 certification. Bringing an existing codebase up to the Basic or Intermediate level will help those projects achieve compliance and enable us to deploy more standardized clients and servers across the network. Talk with the maintainers of client, server, and library projects to figure out what the "gap" is for your codebase of interest.

Personal Eventing

Several years ago we defined a robust protocol for generalized "publish-subscribe" (pubsub) functionality. More recently we defined a friendly "subset" or "profile" of pubsub that is suitable for IM networks. This "personal eventing" technology will enable us to deploy fun extended presence and social networking features like user moods ("how are you feeling?") and real-time music feeds ("what are you listening to?").

The personal eventing protocol is defined in XEP-0163 and support can be added to both servers and clients. Adding support to a server will involve only the core eventing itself. Adding support to a client will involve eventing as well as event payloads like user mood and user tune.

Message Archiving

Traditionally, Jabber clients have archived or logged messages on the local machine of the user. But what if you use a web client, or you switch back and forth between different devices? It would be great to save your messages on the server so that you could retrieve them from anywhere, so we've defined a protocol for doing just that in XEP-0136. A SoC project could add support for message archiving to a client (especially a web client) or a server.

End-to-End Encryption

We have been working on specifications for end-to-end encryption of XMPP communications. Building support for these technologies is an ambitious project, however it can be broken down into several, more manageable pieces.

First, the following two specifications essentially define a session-based model for XMPP communication. Modifying an existing client or library to properly handle stanza sessions would provide a strong basis for end-to-end encryption, enabling hooks into encryption libraries.

Second, the following two specifications define methods for the end-to-end encryption itself. It makes sense to implement these specifications in a library so that multiple clients can use the underlying code:

Existing Open-Source Projects

Jabber/XMPP technologies are based on a client-server architecture similar to email (well, but better). Thus the main open-source projects are clients and servers. However there are also lots of code libraries you can contribute to as well. The following sections list some of the more popular projects. There are also complete lists of clients, servers, and libraries at the jabber.org website.

Given the large number of existing projects, there is plenty of opportunity for fun SoC work. We prefer that you contribute to existing open-source codebases instead of starting a new codebase, since it will be easier to find a mentor, so use the project lists below to find a good fit. If you have questions about an existing codebase, ask the maintainers of that codebase, post to the main developer list, or join our developer chatroom at xmpp:jdev@conference.jabber.org (yes, we have multi-user chat, like IRC but over the Jabber network).

Clients

Usually clients are instant messaging clients, but Jabber/XMPP is not limited to IM (it's just XML routing, use your imagination). Some popular open-source clients include:

Most of the roadmap project ideas described above can be done in any of these clients, so combine a project idea with a codebase and send in a proposal.

Servers

As noted, Jabber/XMPP technologies use a client-server architecture. There are several open-source server codebases:

Most of the roadmap project ideas described above can be done in any of these servers, so combine a project idea with a codebase and send in a proposal.

Libraries

There are XMPP code libraries for just about every programming language. Some of the main libraries include:

Most of the roadmap project ideas described above can be done in any of these libraries, so combine a project idea with a codebase and send in a proposal.

Cross-Pollination Project Ideas

There are many opportunities for integrating real-time features like user availability ("presence") and instant messaging into other GSoC projects. Many of these may be more appropriate for other mentoring organizations. Here are some ideas:

  • AbiSource or OpenOffice.org -- Add presence icons to documents so that you can see the availability of document authors and click to chat
  • Drupal, MoinMoin, Wikimedia, XWiki, or Zope -- Add authentication against Jabber IDs and/or closer integration with Jabber addresses as identities, presence icons for Jabber users, real-time change notifications via Jabber (why wait for email?), etc.
  • Inkscape -- Building on a 2006 GSoC project, harmonize Inkboard more closely with other Jabber-based whiteboarding systems and protocols.
  • Internet2 -- There is a lot of interest in XMPP technologies among the Internet2 community, ask around in the PIC working group for project ideas.
  • Mozilla or SquirrelMail -- Add Jabber presence icons to show if other user is online (via Jabber-ID email header or other means) and then click to chat or groupchat.
  • Open Source Applications Foundation -- A good personal information manager needs to have support for real-time communications, so a contribution to OSAF's Chandler project makes a lot of sense (integrated presence and IM, etc.).
  • Mono, PHP, Python, or Ruby -- All of these languages deserve core support for XMPP in order to introduce more real-time features into a wide range of applications. Work on one of the existing .NET, PHP, Python, or Ruby libraries (e.g., XMPP Basic compliance) would speed that process along.
  • SIP Communicator -- Closer integration between SIP and XMPP would be quite beneficial for interoperability. Bringing SIP Communicator up to compliance with the XMPP Basic or XMPP Intermediate protocol suite would help quite a bit.
  • Subversion -- Add support for real-time change notifications via Jabber.
  • Ubuntu -- There is some work on integration of Jabber messaging into Ubuntu, ask around in the Ubuntu community.
  • Wordpress -- Add better integration with Jabber addresses, inclusion of real-time user information in blog pages (e.g., current mood and tune), verification of comments via "ping" back to Jabber user (XEP-0070), real-time change notifications via Jabber, support for Atom Over XMPP via publish-subscribe, etc.

Insert Your Idea Here!

Although we have ideas for projects, your ideas may be better. :) Feel free to come up with your own creative proposal that does not address one of the project ideas listed on this page.

Other Project Ideas

Igniterealtime.org Project Ideas

Several projects ideas for the Open Source projects hosted at igniterealtime.org (Openfire, Spark, Smack):

   * Asterisk-IM: Asterisk and Openfire Integration
   * Link-Local Messaging (XEP-0174) support
   * File transfers for gateways
   * Jingle Voicemail
   * Group Chat for Gateways
   * G722 Codec for JMF

For more details, visit the ignite project ideas page.

Coccinella: Jingle file transfer

Project motivation

Transporting files from one user to another is plagued by NATs and firewalls. In ancient times a standard Tcp connection was all that was needed. Instead various application level protocols have been implemented on top of Udp which handles NATs much better. This "reinventing the wheel" by having to reimplement a kind of pseudo Tcp stack on top of Udp is a very unfortunate situation which lacks standardization.

Implementation

This projects aims to use Google gTalks Jingle implementation as a starting point. Ufortunately it is written in C++ and deeply tied into the application notifier system and therefore not reusable as is. Instead the task will be to use the Tcl Udp C code implementation, and essentially use gTalks PseudoTcp class as a wrapper. There are two possible options here: either do a pure Tcl script implementation of the tricks used in PseudoTcp, which I'm not sure is possible, or just translate the C++ class into C code and wrap up the tcludp package to a pseudo tcp (ptcp) command. This should work just like the standard Tcl socket command and should be able to use it transparently.

Jingle contains several parts but the actual jingle xmpp protocol stack is already running and used for voip. A limited STUN client has also been implemented in pure Tcl, but some support for the ICE protocol will likely be necessary.

Relevant XEPs

There seems to be a XEP in the works that actually describes the topmost file transfer protocol.

Coccinella: an aquarium for kids

  • Mentor: Mats Bengtsson
  • Programming language: Tcl/Tk
  • Coolness factor: high

Project description

This project involves the creation of an interface for kids to Coccinella. You need to create a new roster style, the fishy roster style, with an aquarium containing fishes that represents the contacts (like ralphm's Jabber Aquarium). The fishes need to be be animated with User Mood. For example, when a contact is happy, the fish will swim quickly in the aquarium with a smile on his face. The graphics will be done in 2D, but when time allows, they can be made in 3D.

The programming tools will be Tcl/Tk and the tkpath graphics extension package [1] which provides high quality graphics on all platforms. There exists an albeit primitive SVG importer so the actual graphics elements can be obtained from a SVG drawing tool.

This project will involve mostly new code, and less boring code rewriting.

Relevant XEPs

Gajim: Jingle VOIP

  • Mentor: Yann Le Boulanger

Project description

The goal of this project would be to add to Gajim the ability to do VOIP. The famous Jingle XEP is needed. So first step is to analize all possibilities for using it, and then implement one. Gajim is written in python, with PyGTK interface. It uses a modified version of xmpppy as lowlevel library.

Relevant XEPs

xmpp4moz: Shared-over-XMPP Web Applications

Project motivation

On the web, people interact with web applications; in instant messaging, they interact with other people. By bringing XMPP to the browser we can mix the two scenarios and allow people to interact with other people on web applications. The result is richer forms of interaction (e.g. shared editors, games, whiteboards, ...) that can be deployed to everyone with the ease of web applications, i.e. by just uploading pages to a server and giving away a URL.

Implementation

This area is little explored, so you'll need creativity just as much as (if not more than) technical skills, and (of course) should have no fear of pushing the perceived limits of today's web.

The project involves creating a shared web application of your choice (a collaborative editor, a game, etc.), preferably in a way that allows later extraction of generic, reusable code (maybe along the lines of XSI), as well as of good practices for future development in the area.

Relevant documentation

Extended addressing support

XEP-0033 is a XMPP extension which can save a lot S2S (Server to Server) traffic and let you easily send messages to more than one contact, even with cc and bcc recipients you used to know from electronic mail. The XEP hasn't changed since 2004 but there are only some implementations at the moment. So your project could be to add support for XEP-0033 to your open source server of choice. If that isn't enough some servers, e.g. eJabberd, have own components for PubSub and MUC so if adding XEP-0033 support to those servers it should be easy for you to add support to the included components too.

Data Forms Framework

Build a X-Data framework consisting of:

  • Visual X-Data forms editor
  • application to send forms to entities, analyze and store the submitted results
  • replace memberbot with this application.

Publish-Subscribe Based Package Management System for an Open-Source Operating System

This is how it should work on the client side:

  • During installation of the distribution, a Jabber account is registered (or SASL Anonymous is used) and the user will be subscribed to the Publish-Subscribe nodes representing the repositories he is interested in.
  • When the distribution is started, a daemon is started which is a Jabber client.
  • When the daemon receives a notification, it will inform the user or update the package, depending on the user's preferences.

This is how it should work on the server side:

  • Publish-Subscribe nodes for each package (or each repository?).
  • Initially, the system can use an existing repository, and get updates each minute e.g. In a later stage, the system should be notified when a new package is uploaded to the server.
  • All users subscribed to a node will get instantly a notification regarding the new version of the package.

Motivation:

  • Increase end-user satisfaction

Advantages over current pull based systems:

  • safer as you will be notified about updates in real-time
  • faster and less server load/traffic (you don't have to download 5MB or something like that)
  • a sexy showcase project for XMPP
  • improved security when using secured XMPP connections
  • xml:lang to allow multi-lingual information about updates
  • Improved security: using this system, the package maintainer can notify all users of the package regarding a security issue in an application for which there is not yet a fix. In this way the user can avoid using the application until there is a fix, or depending on the user's preferences, the system can automatically disable the application.
  • better feedback possible (see also next project idea)

Requirements:

  • scalability
  • easy/transparent
  • client & server
  • secure: PGP, SASL, TLS,...

Feedback System for Open Source Packagers

Note: This can be a follow-up project of the previous project, eventually two students can work on those projects.

Motivation:

  • Increase end-user satisfaction regarding their open source system and better feedback for packagers and software projects.

If a user finds a bug in an application, or if he just has a nice idea about a cool feature, he should be able to easily contact the package maintainer and/or other people involved in the software project. The user should be able to chat with those people and give them feedback. The package maintainer also can notify this specific user when he fixed the bug or implemented the feature request. It would be also nice to send translations, patches,... using this system.

Requirements:

  • way to point to the project's Multi-User Chat room (in the package or via the XMPP server?)
  • way to point to the Jabber ID of the maintainer (in the package or via the XMPP server?)
  • way to point to other people involved in the project (in the package or via the XMPP server?)
  • way to see the presenc of all these people
  • server-side logging?
  • security
  • nice and easy to use user interface, preferably extending an existing interface

Tunneling (asynchronous) Web Services for Bioinformatics application over XMPP by supporting Ad-Hoc Commands (XEP-0050) and IO-Object Forms

The student's challenge is to write server components and/or client implementations that export/import Web Services for Bioinformatics by making use of XEP-0050 - Ad-Hoc Commands and the yet to be council-voted IO-Object Forms. Client implmementations could be developed as Plug-In for the Bioclipse Bioinformatics IDE that was recently introduced in BMC Bioinformatics. Web Services for Bioinformatics may base on existing databases or algorithms, for example by routing GenBank entries through XMPP.

Mentor: Johannes Wagener