XWiki and Google Summer of Code 2009

XWiki is accepted for the fifth year as a mentoring organization for GSoC 2009. The coding period has begun and lasts until August 17<sup>th</sup>. You can monitor the student progress on the dedicated wiki.

This page hosts information and project ideas for the Google Summer of Code 2009. Students can come up with their own ideas, and propose them on the mailing list or the IRC channel.

The XWiki GSoC 2008 page is over here.The XWiki GSoC 2007 page is over here.


Invalid macro parameters used for the "toc" macro. Cause: [Failed to validate bean: [must be greater than or equal to 1]]. Click on this message for details.

Suggested way of working for SoC students

Important Dates (timeline): http://socghop.appspot.com/document/show/program/google/gsoc2009/timeline

First and foremost, working on XWiki needs to be fun and a good learning process! However the XWiki project is already following some development rules that we're asking SoC students to follow too. This is for the good of the XWiki project but more importantly it's a good way to learn how an open source community works and if these practices are followed then it'll be much easier to integrate the resulting work into XWiki's official releases.

So here are some practices we'd like SoC students to follow (please comment on the list if you'd like to change some of them or propose other things):

  • SoC students should be considered like any XWiki contributor which means they should respect the same rules and which means they are not committers on XWiki core. Note that a SoC student can become a Committer in the same manner a contributor can become one.
  • SoC students will be given commit access to the sandbox only where they'll create their project (one top level directory for each project). For projects which need to modify some existing code, JIRA issues will need to be created and patches attached. It's important that patches be of good quality and small in order to be applied quickly. Once sandbox projects reach a good level of maturity (meaning they work and the code is of code quality, documented, etc) then we'd like to migrate them to the main release tree.
  • SoC students should obey all Community rules. For example this means:
    • using the XWiki coding conventions
    • using the defined communication channels: IRC and mailing list
    • etc
  • SoC students have time allocated to familiarize with XWiki development process. As such we'd like each SoC student to pick one or several existing issues in JIRA and send a patch that fixes it/them before that period ends (from April 20th to May 23rd) This is a critical integration step to ensure all SoC students understand how XWiki works and it's a chance to start asking questions and get to know each other.
  • SoC student should post a quick introduction on the xwiki dev mailing list to explain who they are and what they're going to work on.
  • SoC student should always go to the list when communicating about their project. They should not talk directly to their mentors. They should use the XWiki IRC channel if they need to talk to them. The goal is that everyone in the XWiki community help them, answer their questions but also know what they are doing. This will make patch applications and integration of their work back into XWiki trunk easier later on. This is very important and a criteria of success for the student. This is about learning how open source works... Note that student can also CC their mentor's email address if they want but the mails have to go to the XWiki dev list.
  • SoC students should not block on anything for a long period of time. They should ask plenty of questions on the list (but they should also be autonomous!)
  • SoC students should be as much as possible in contact with the community, following the mailing lists (and answering mails, when they know what to say), stay on the IRC channel, give regular status updates on their project. This does not mean that a SoC student is not allowed to take a break, of course, but that while working a student should be integrated as much as possible with the community.
  • When taking a vacation/break, notify the mentor; a mysterious disappearance could lead to a negative feedback afterwards.

    Remember that this is not a summer job, or a Rent-a-coder like project, but a rewarded successful integration in an free software/open source community. If all you are interested in is the money, then better look for a real job, as Free Software requires passionate people; an ideal candidate is more interested in the t-shirt.

Conditions for success

Students will need to meet these criteria for sucess:
  • 1) Must have something that works and is in some finished state.
  • 2) Must be integrated or close to be integrated in xwiki without too much effort
  • 3) Must have interacted correctly and continuously with the community
  • 4) The work must have been enough (it's supposed to be a 2 men/month effort)

    Note that the real important part is 3) since this is a criteria for success for 1), 2) and 4).

Student Application template

Please use this template as the basis for your student application which must be submitted to google.

Proposed Projects

  • XWiki Jabber, Google Talk, Skype Integration

    25 projects proposed in total.

    Anti Vandalism Filters

    In a closed environment, like a private intranet, the access rules and restricted registration allow a site adiministrator to control what each user can do inside the wiki. However, an open wiki with public access can easily become the target of spam bots and malicious users, which cannot be excluded while still maintaining the open characteristic.

    The idea of this project is to enable prevention and recovery techniques aimed at reducing the number of vandals that can damage the wiki. For example, some prevention mechanisms include:

    • A better CAPTCHA integration
    • Detection of clients making mass requests
    • Detection of bad edits based on the entered text
    • Integration with an anti-spam service that lists "bad" IPs

    Recovery mechanisms basically include mass revert of edits and document deletions from a given IP or username.

    Coordinated by . Estimated workload: 3 months.

    Import from other popular blogging platforms

    With the new blog application, XWiki has powerful blogging abilities. It would be nice to be able to import existing blog posts from popular platforms.

    Coordinated by . Estimated workload: 2 months.

    Calendar application

    The previous Event Calendar in XWiki was very basic: in a monthly view, it would allow to add and display events stored as XWiki objects in the calendar's wiki document. This application was recently removed from the default distribution of XWiki Enterprise, as it did not meet the quality and usability requirements.

    We wish to recreate the Event Calendar application, such that it would allow to:

    • display day, week, month, year view for the calendar
    • store the event objects anywhere in the wiki
    • have a friendly UI for adding, changing and filtering events
    • import events from the old version event calendar.
    • support microformats
    • export in standard formats (ical)

    The application should have a friendly AJAX UI, but should also be somewhat functional in browsers without JavaScript. It must be easily skinnable through CSS. SmartGWT is a viable option for the implementation.

    Coordinated by . Estimated workload: 2 months.

    Chart Macro for Syntax 2.0 and Chart Wizard

    The Chart Macro and Wizard was a GSoC 2005 Project. Now XWiki is using a new macro and syntax system. The plugin and wizard need to be adapted to this new architecture.

    The Macro should be compatible with XWiki Syntax 2.0. The Wizard should integrated in the new Wysiwyg (GWT either native or through wrapping). It should support editing of chart configurations.

    Coordinated by . Estimated workload: 3 month.

    DimDim Integration

    A possible and interesting project would be to support launching a WebConference using opensource software DimDim directly from XWiki

    Coordinated by .

    GWT Wysiwyg Improved Multi Browser Support

    Currently, the new GWT Wysiwyg editor supports Firefox 2 and 3, and IE 6 and 7. This project consists of:

    • analyzing how the editor behaves on other browsers (opera, safari, chrome?, IE8, FF 3.1) and finding the points where development is needed
    • fixing bugs / implementing APIs for as many browsers as possible from the list above
    • setting up automatic testing methods to be able to maintain the multi browser support.
    Coordinated by . Estimated workload: 3 man month.

    Google Docs Integration

    In 2007, an experimental Summer of Code project (http://dev.xwiki.org/xwiki/bin/view/GoogleSummerOfCode/Google+Docs+Integration) successfully integrated Google Docs with XWiki, demonstrating the edition inside XWiki of a Wiki table as a Google Spreadsheet document. The Google Docs API at that time had serious limitations, not allowing to do more.

    The objective of this project is to continue the Google Docs integration, by allowing to edit an attachment in Google Docs, to support other document types, such as Text and Presentations, to support the new rendering engine and new XWiki 2.0 syntax, and also to improve the performance and usability of the integration.

    Coordinated by . Estimated workload: 3 man month.

    Google Gadget and OpenSocial Integration

    Based on the work already done for integration Google Gadgets (http://incubator.myxwiki.org/xwiki/bin/view/Gadgets/), a full integration is the objective including OpenSocial Integration. This project could also include create XWiki Pages that perform as Gadget Dashboards (like iGoogle or NetVibes) and allow to drag and drop Gadgets and move them around in the page

    Coordinated by . Estimated workload: 3 month.

    Import Export from any other Wiki

    Create a extensible framework to import export data between wikis. This should handle converting the data in the pages including links between pages and metadata as well as direct access to the data through either a web service (prefered) or database or the file system

    The system should at least for MediaWiki and Confluence in import mode

    Coordinated by . Estimated workload: 3 month.

    Improved Bulletin Board Application

    A bulletin board application for XWiki was coded about 1 year ago. It would be great to improve it and add new features to make it as good as other alternatives such as PHPBB.

    The successful candidate will have HTML, CSS & JS skills and the willingness to learn about XWiki's data model. He will have a working knowledge of bulletin boards, ideally by having used one previously.

    Coordinated by . Estimated workload: 2 months.

    Improved PDF Export using XML-FO and FOP

    XWiki has PDF export using XML-FO and FOP. It needs to be improved to create much nicer PDF documents (nicer fonts, better image sizing, support for header and footers, support for pagination and TOC). 

    This project is hard and requires XSLT experience. 

    This project is related to PDFExportusingtheOfficeImportplugin

    Coordinated by . Estimated workload: 3 months men.

    Improved content fetching mechanism for XWiki Watch

    The feed reader plugin that Watch is currently using should be improved to maximize content fetching from feed sources. Also, building a whole new module allowing content fetching from other web sources (e.g. semantically marked html pages, relying on technologies that would address a range of content as wide as possible e.g. GRDDL)

    Coordinated by . Estimated workload: 2 man month.

    Full JSR 168 (portlet) compatibility

    A while ago, XWiki could be integrated with eXo, a "friend" project providing portal services. But the integration was not maintained, as few people ever asked for it.

    The goal of this project is to review/finish the existing portlet implementation, making sure that XWiki can be used in at least 2 portal containers.

    See also: http://jira.xwiki.org/jira/browse/XWIKI-602

    Coordinated by . Estimated workload: ?.

    Integration of Mozilla Bespin as a core Script editor in XWiki

    Pushing further the initial hack of Bespin in XWiki and the Skin Editor application developed from it by integrating Bespin's editor as the script editor of XWiki's platform. The script editor would be a third alternative to the current Wiki and WYSIWYG editors, for developers. It would be available to edit wiki pages, or text-area properties of semi-structured data (for example to write scheduler jobs in the groovy language). The integration could then be pushed further writing XWiki Syntax 2.0 coloration engine, or writing new XWiki-specific commands, in order to make in-wiki developers more efficient (example: dynamic XWiki API help).

    Coordinated by . Estimated workload: 3 month men.

    New XEclipse Navigator

    XWiki Eclipse (or XEClipse for short) is a desktop tool that allows to edit, view, save or delete pages located on an XWiki server. It can be used as a standalone desktop application or as an Eclipse plugin. Its main usages are productivity, offline and application development in XWiki pages.

    XEclipse provides a navigator view that allows a user to display XWiki resources in a hierarchical view and navigate through them. Currently the navigator is quite basic, it displays spaces, pages and objects. The goal of this project is to improve the current navigator in order to support the display of more XWiki resources (i.e., attachments, translations, etc.) and support advanced functionalities like drag&drop, state persistence and a better integration in the workbench.

    Coordinated by . Estimated workload: 2 months.

    PDF export using the OpenOffice Plugin

    The Office Importer controls an OpenOffice server to perform transformation from Office docs to Wiki syntax, but it also supports converting to PDF.

    We would like to use this feature to create very nice Word and PDF export from a Wiki document. We need for this to generate a nice XHTML+Images and pass it to the Office Converter which is part of the OfficeImport plugin. The objective is to have very nice exports with support for TOC, pagination, page breaks, great image sizing, landscape support, etc..

    This project is related to ImprovedPDFExportusingXMLFOandFOP

    Coordinated by . Estimated workload: 3 month.

    Photo Album Application

    The previous Photo album in XWiki was very basic, allowing only to create albums with a description, add photos without any information attached to them and browse through these photos in simple manner. This application was recently removed from the default distribution of XWiki Enterprise, as it did not meet the quality and usability requirements.

    We wish to recreate this application, with the following features:

    • creation of albums, with additional data attached to them: title, description, date(s), location
    • adding and managing photos and information about them (such as description, date, location, author, camera information, etc)
    • view as thumbnails and slideshow (with adjustable timer and with manual browsing)
    • migration tool from the old version photo albums.

    The application should have a friendly AJAX UI, but should also be functional in browsers without JavaScript. Il must be easily skinnable through CSS.

    Coordinated by . Estimated workload: 2 months.

    Skin and template support for XOffice

    XOffice is a project which allows users to browse,create, attach and edit wiki documents inside Microsoft Office. XWord is an Word extension that allows users to do powerfull WYSIWYG editing, and collaborate over advanced rich content. Currently XOffice does not have an effective mechanism for handling styles in a consistent manner with the XWiki Server. Additionally, the Wiki syntax of a Word edited page is usually messy because of style data. Proposed features/bahavior for this new module:

    • Gather skin data and save it locally in CSS files usable by XWord
    • Inline, WordML and exernal styles generated by Word should be integrated in XWiki using style extension objects.
    • WYSIWYG editing should toggle skin styles, so that the editing would be skin dependent or independent.
    • Create templates from style data. These templates will be used for editing under style constraints and ensure consistency over the wiki.
    • Lock & Unlock skin regions,like headers and footers, and allow modifications using Content Controls. The new data should be stored in new skin objects or style extensions on the server and templates locally. Modifications can be done at wiki, space or page level.
    Coordinated by . Estimated workload: 3 month.

    Survey Application

    We working with a community it is very usefull to be able to survey your community. We would like a user of the wiki to be able to create a new survey with typical question types (open, list with single select, list with multiple select, etc..). The survey definition should be stored in an XWiki class.

    The survey should include a way to notify a list of users that the survey is open. The survey should store each response in a separate XWiki document using a class.

    The survey application should include a survey report in text and using the chart plugin already existing in XWiki (based on JFreeChart). It could also use Google online visualization.  

    Coordinated by . Estimated workload: 3 month.

    Template and Document Type Manager

    A Wiki manages document and XWiki has the powerfull ability to manager semi-structured documents thanks to the object model. 

    When users want to create a new document we want to give them the ability to create a new document from a template. This template can be a pure wiki content document but can also be a structured document using an XWiki Class. The create from template feature alreay exists in the xwiki core.

    What we want the SOC project to build is a Template Manager allowing to select a page from the wiki and make it a template. Then we want the create buttons to open a UI allowing to choose a template. Templates should be organized by tags.

    If the student is efficient enough the next step would be to expose the XWiki Class system for non programmers allowing to create a simple structured document with simple fields (text, textarea, date, list) from the simplest UI possible (current the XWiki Class definition has too many options for basic users) and generate the display script of this document type automatically.

    The result of this project should be well integrated in the XWiki UI.

    Coordinated by . Estimated workload: 3 months.

    Wiki Activity Gadgets

    Specify and implement gadgets that represent different types of activities/statistics on a wiki, a wiki space or page


    • World map of wiki users
    • Timeline of edits for a wiki / space / page
    • Dynamic chart showing contributions over time
    • bar charts showing contribution (both positive and negative) total sizes by author for a page
    • word cloud for a page / space / wiki
    • ... more to be defined - this is part of the work

    Can be usefull:

    Coordinated by . Estimated workload: 3 months men.

    Integration of various source editors in XEclipse

    Integrate various Eclipse core or plugins editors in XEclipse, to offer a better in-wiki developer experience. The integration should focus on easing the web parts of in-wiki development when using XEclipse (http://extensions.xwiki.org/xwiki/bin/view/Extension/XWiki+Eclipse). It should for instance allow to write JavaScript and StyleSheet extensions using proper JS and CSS editors. Same for the groovy language and python, which are supported in XWiki pages. See for example:

    Coordinated by . Estimated workload: 2 men month.

    XOO - XWiki integration with OpenOffice

    XWord is an extension for MS Office, which allows users to browse, create and edit wiki documents, or upload and download attachments, all from inside MS Word. Although inside enterprises MS Office is still the most used Office suite, people from the Open Source community have been asking for an equivalent product built for the OpenOffice suite.

    Given that the two products are using different technologies (XWord is written using .NET/C#, while XOO must be written using C++ or Java), this project needs to be written from scratch, but making use of the experience gained from writing XWord.

    The main features of XOO would be:

    • A wizard for connecting to an XWiki server
    • A navigation panel for browsing the documents inside the wiki
    • Downloading and uploading attachments
    • Editing attachments supported by OpenOffice
    • Editing wiki documents in OOWriter
    • Creating new documents
    Coordinated by . Estimated workload: 3 months.

    XWiki Cross Platform Web and Desktop Widget

    The objective is to spread the use of your Wiki. In order to do this we need to make your wiki content accessible from any existing widget platform:

    • iGoogle, NetVibes, My Yahoo
    • Facebook, OpenSocial
    • Desktop widgets (Google Desktop, Windows Vista, Dashboard)
    • Custom Desktop application (Firefox extension, Windows Tray)

    The Widget should show the most important information from the Wiki (what's new, stats, members, watched pages) but also be extensible by adding pages created in the wiki to show information in the widget

    The widget should include notifications features (using AJAX or internal scheduler) to warn of new content.

    The widget should support multiple wikis in a nice UI.

    Coordinated by . Estimated workload: 2 man month.

    XWiki Jabber, Google Talk, Skype Integration

    The objective is to integrate the major IM tools with XWiki. It should be very easy to start a chat in any of these tools with members of the Wiki. For example, editors of a page or members of a group (XWiki group or Workspaces space) could be invited to join a chat.

    The tool then should allow to archive the chat in wiki pages. 

    The tool should allow to list the chats actively launched or monitored by the wiki.

    This can be done using a Jabber client or with a dedicated Skype instance remote controled. 

    A Jabber AJAX chat tool can also be integrated for users not having Jabber or Google talk installed. 

    This should work with public Jabber server and also with private Jabber servers.

    In case of public servers (Jabber,GTalk,Skype) the users will list their ID in their profile.

    In case of a private server the Jabber server would be fully integrated with the wiki (the wiki or LDAP being the source of users)

    More details:

    For me the first thing would be:

    1/ Chat Archiving

    We create a user for the wiki on these networks and we can subscribe the wiki to a chat and have the wiki record it.

    We should have the nicest display possible of the chats in the wiki

    This feature is not easy to write for Skype but it would be really great to have it for skype. It might need to be running a skype instance under linux /windows and control it using Java.

    2/ Chat integration

    Users can either register their Jabber account or will automatically have one if there is a jabber server associated to the wiki (XWiki would automatically create the Jabber account).

    Then the user can have a page to chat but could also have an integration of Chat like Facebook. I would say best would be to inspire a lot from the Facebook chat integration. There would be an option to record any of the chats in the wiki. It should be possible to link a chat to any XWiki Group that exists in the wiki. It should be possible to launch a chat with any visitors of a page or space in the last "X" minutes (we can modify the statistics module to report latest visitors on a page or space, that would be a nice API to have).

    Skype integration could be achieve thanks the the karaka project (http://code.google.com/p/karaka/) which provides an XMPP gateway to skype

    Coordinated by . Estimated workload: 3 man month.
Created by Marta Girdea on 2010/02/10 11:40

Get Connected