60
edits
Difference between revisions of "Summer of Code 2010 Project Ideas"
Jump to navigation
Jump to search
Summer of Code 2010 Project Ideas (view source)
Revision as of 02:23, 28 March 2010
, 02:23, 28 March 2010Inline ideas from Prosody GSoC page, and various other improvements to the page
(Inline ideas from Prosody GSoC page, and various other improvements to the page) |
|||
| (3 intermediate revisions by the same user not shown) | |||
| Line 3: | Line 3: | ||
== High-Level Priorities == | == High-Level Priorities == | ||
The high-level priorities for the XMPP community | The high-level priorities for the XMPP community are listed here with summaries (see also the [http://xmpp.org/xsf/roadmap.shtml XSF Roadmap]). You may work to implement them in any of the clients, servers or libraries lacking support (see the project-specific lists below). | ||
Choose which project you would like to work with, based on the language their codebase is written in, and how well you fit with their community. Discuss your proposal with them directly to see if it is a good idea. | |||
=== Jingle File Transfer === | === Jingle File Transfer === | ||
| Line 14: | Line 16: | ||
* [http://xmpp.org/extensions/xep-0260.html XEP-0260: Jingle SOCKS5 Bytestreams Transport Method] | * [http://xmpp.org/extensions/xep-0260.html XEP-0260: Jingle SOCKS5 Bytestreams Transport Method] | ||
* [http://xmpp.org/extensions/xep-0261.html XEP-0261: Jingle In-Band Bytestreams Transport Method] | * [http://xmpp.org/extensions/xep-0261.html XEP-0261: Jingle In-Band Bytestreams Transport Method] | ||
Pidgin already has Jingle File Transfer, but it still needs implementing in other clients and libraries, see below. | |||
=== Reliability Improvements === | === Reliability Improvements === | ||
| Line 19: | Line 23: | ||
The XSF has defined two specifications that make XMPP communication more reliable: [http://xmpp.org/extensions/xep-0198.html Stream Management] and [http://xmpp.org/extensions/xep-0184.html Message Receipts]. We won't know if these technologies solve the problem until we have more implementation and deployment experience, so we need to get busy coding. | The XSF has defined two specifications that make XMPP communication more reliable: [http://xmpp.org/extensions/xep-0198.html Stream Management] and [http://xmpp.org/extensions/xep-0184.html Message Receipts]. We won't know if these technologies solve the problem until we have more implementation and deployment experience, so we need to get busy coding. | ||
''I (MattJ) have some server-side code for XEP-0198 (Stream Management) in Prosody, and am willing (and very interested) to work with someone adding support to a client so we can get a pair of interoperable implementations going this summer.'' | Servers, clients and libraries need this support (see below). | ||
''I (MattJ) have some server-side code for XEP-0198 (Stream Management) in Prosody, and am willing (and very interested) to work with someone adding support to a(ny) client so we can get a pair of interoperable implementations going this summer.'' | |||
=== Mobile Optimizations === | === Mobile Optimizations === | ||
| Line 60: | Line 66: | ||
== Specific Server Projects == | == Specific Server Projects == | ||
=== Prosody === | === Prosody === | ||
Prosody is a lightweight XMPP server written in Lua. It is designed to be modular and easily extensible via Lua plugins. | [http://prosody.im/ Prosody] is a lightweight XMPP server written in Lua. It is designed to be modular and easily extensible via Lua plugins. Members of the Prosody development team would consider mentoring students on any of the following projects: | ||
==== | |||
==== Server Side Message Archiving ==== | |||
''Difficulty: Medium'' | |||
Support for server-side message archiving, as described in XEP-0136. This would allow the server to be a central repository for all the user's conversation logs. | |||
The [http://gajim.org/ Gajim] client project has an implementation of this XEP, and you should work with them to ensure interoperability between Gajim and Prosody. | |||
==== IPv6 support ==== | |||
''Difficulty: Easy for someone with knowledge of C and networking'' | |||
IPv6 is support in protocols and networks is becoming increasingly important as the IPv4 address space diminishes. We need to encourage the use of IPv6 on the XMPP network, but Prosody and the Lua socket library it uses (LuaSocket) don't support IPv6. The project would involve both C (LuaSocket) and Lua coding (Prosody's DNS and connection-handling code) to allow for easy use of IPv6 connections for both c2s and s2s. | |||
==== Web interface ==== | |||
''Difficulty: Easy'' | |||
A dynamic web interface for managing the server. This would ideally use [http://xmpp.org/tech/bosh.shtml BOSH], [http://code.stanziq.com/strophe Strophe.js] and [http://xmpp.org/extensions/xep-0133.html XEP-0133] to make it a server-independent project. The primary language would be Javascript, with a possibility of some Lua. | |||
==== Pubsub support ==== | |||
''Difficulty: Medium'' | |||
A mod_pubsub for Prosody, implementing [http://xmpp.org/extensions/xep-0060.html XEP-0060]. In the spirit of Prosody it should be simple, modular and extensible. | |||
==== Spam/abuse prevention ==== | |||
''Difficulty: Easy-Medium'' | |||
Although spam and abuse isn't prevalent on XMPP as it is on most other networks, it's on the rise. Implement a range of features to help stop this trend, and help service administrators keep on top of abuse on the network. | |||
Links: | |||
* [http://xmpp.org/extensions/xep-0158.html CAPTCHA Forms] | |||
* [http://xmpp.org/extensions/xep-0275.html Entity Reputation] | |||
* [http://xmpp.org/extensions/xep-0268.html Incident reporting] | |||
==== The ultimate server migration tool ==== | |||
''Difficulty: Medium'' | |||
The Prosody team have developed many tools for converting the different server storage formats around. Unify them and produce a tool capable of reading the data from one server and exporting another supported format (e.g. [http://xmpp.org/extensions/xep-227.html XEP-0227]), making server migration painless, no matter where you are moving from or to. | |||
=== jabberd2 === | === jabberd2 === | ||
| Line 71: | Line 106: | ||
* [http://xmpp.org/extensions/xep-0163.html XEP-0163]: Personal Eventing Protocol | * [http://xmpp.org/extensions/xep-0163.html XEP-0163]: Personal Eventing Protocol | ||
* [http://xmpp.org/extensions/xep-0136.html XEP-0136]: Message Archiving | * [http://xmpp.org/extensions/xep-0136.html XEP-0136]: Message Archiving | ||
=== Openfire === | |||
[http://www.igniterealtime.org/projects/index.jsp Openfire] is the award-winning, open alternative to proprietary instant messaging based on the Java programming language. It is modular and extensible via its plugin architecture. | |||
==== Ideas ==== | |||
* [http://www.igniterealtime.org/issues/browse/OF-162]: Multi-domain support | |||
* [http://xmpp.org/extensions/xep-0227.html]: Portable Import/Export for XMPP servers | |||
* [http://www.igniterealtime.org/community/message/202083#202083]: Reducing the database footprint of Rosters in Openfire (possibly replacing the relation persistence model with a new model based on nosql-techniques) | |||
* [http://www.igniterealtime.org/community/docs/DOC-1925]: Constructive performance enhancements, which would include finding a structural solution to Openfires Achilles' heel | |||
* [http://www.igniterealtime.org/community/message/202083#202083]: Constructive spec compliance enhancements | |||
* [http://www.igniterealtime.org/community/message/202083#202083]: Network application framework porting effort from Apache MINA to Netty | |||
* [http://www.igniterealtime.org/community/docs/DOC-1992]: Clustering solution development | |||
* [http://www.igniterealtime.org/community/message/202083]: Automated functional testing | |||
* [http://www.igniterealtime.org/community/docs/DOC-1876]: Fastpath webchat support | |||
== Specific Library Projects == | == Specific Library Projects == | ||