XWiki @ Google Summer of Code 2010

Last modified by Ecaterina Moraru (Valica) on 2020/01/28 14:36

Unfortunately, XWiki will not take part in Google Summer of Code 2010 as a mentoring organization. However, if you like one of the projects proposed on this page and you would like to contribute, don't hesitate to contact us on the mailing list or the IRC channel.

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

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

Suggested way of working for GSoC students

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 GSoC 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 GSoC students to follow (please comment on the list if you'd like to change some of them or propose other things):

  • GSoC 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 GSoC student can become a Committer in the same manner a contributor can become one.
  • GSoC 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.
  • GSoC 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
  • GSoC students have time allocated to familiarize with XWiki development process. As such we'd like each GSoC student to pick one or several existing issues in JIRA and send a patch that fixes it/them before that period ends (from April 26th to May 24th) This is a critical integration step to ensure all GSoC students understand how XWiki works and it's a chance to start asking questions and get to know each other.
  • GSoC 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.
  • GSoC 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.
  • GSoC 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!)
  • GSoC 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 GSoC 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.

Good generic advises:

Conditions for success

Students will need to meet these criteria for success: 

  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 (21)

As of now, we're still in a brainstorming phase and the projects proposed below are just wild ideas at this stage. We encourage everyone to propose ideas. Then we'll have a community vote later on to decide which ones we are interested in for GSoC 2010. Students will then be able to pick from these selected projects, discuss them with us or even propose other subjects. We also recommend students interested in joining XWiki for GSoC 2010 to manifest themselves as early as possible so that we can start working with them on this project list.

Annotations for images and other content types

Extend the Annotations Module (svn, demo) in order to allow annotating images and sections of images.

Additionally, research and implement a method to add and visualize annotations on document attachments: .pdf, office documents (word, presentation), etc.

Coordinated by

. Estimated workload: 3 months. Read more...

Auto Completion in Content Editors

The general goal is to allow auto completion in Wiki and WYSIWYG editors for inserting links, images, macros and more. In practice you'd start typing some characters and you'd get a completion list as you get in Java IDEs for example. Here's an example: you start typing "[" and you get a list of documents to which you've recently navigated to, you continue typing letters and the suggestion lists narrows to documents containing this letter, etc.

One goal is to make the WYSIWYG editor as fast to use as the wiki editor.

For details see http://jira.xwiki.org/jira/browse/XWIKI-206 See also the implementation done by Confluence: http://confluence.atlassian.com/display/DOC/Confluence+3.2+Beta+Release+Notes

In addition a secondary goal could be to support wiki syntax in the WYSIWYG editor (for example with an option to activate the wiki syntax mode for a given syntax). In this mode if the user types, for example, "*hello*" then it's transformed into bold. This would allow to benefit from the best of both worlds.

To summarize the general goals of this project are:

  • Speed up content editing in both WYSIWYG and Wiki editors
  • Make the wysiwyg editor attractive to advanced users too and make it approach the speed of the wiki editor

Coordinated by

. Estimated workload: 3 months. Read more...

CMIS Integration

CMIS (Content Management Interoperability Services) is a proposed standard for improving interoperability between Enterprise Content Management systems (http://en.wikipedia.org/wiki/Content_Management_Interoperability_Services)

The idea is to implement a CMIS layer that will provide XWiki content to clients.

The CMIS specs proposes two types of bindings 1) A RESTful one based on AtomPub 2) A SOAP one 

The project will focus on the RESTful binding.

The implementation would leverage the Apache Chemistry framework and will be integrated in the current REST backend of XWiki (taking into account also the needed modifications)

Links:

Coordinated by

. Estimated workload: 3 months. Read more...

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 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.

Coordinated by

. Estimated workload: 2 months. Read more...

XOffice - Add Excel and PowerPoint addins

  • Office importer is a XWiki application and a platform module that allows the user to import office documents in XWiki.
  • XOffice is a XWiki.org project that integrates Microsoft Word with XWiki.
    Currently XOffice only contains add-ins for Word 2003,2007, and 2010. Two more add-ins can be added  to PowerPoint and Excel. The primary purpose of the add-ins would be to export the documents to XWiki.
    Steps:
  • Add the office importer functionality to the REST or XmlRpc API.
  • Refactor XOffice to better suite future add-ins
  • Create the Excel Add-in
    • Export excel documents to xwiki by using office importer or use office preview
    • Automatic detection of editable tables in xwiki pages & content updating
  • Create the PowerPoint add-in
    • Export presentations to xwiki by using office importer/preview

Coordinated by

. Estimated workload: 3 months. Read more...

Export To Word / PDF through OpenOffice

Based on the Office Importer (with OpenOffice in the backend) and XWiki Rendering components, build a module to export wiki documents and attachments to WORD/PDF format. The wiki or attachment document should be converted to HTML or passed as is to the OpenOffice component to build a Word or PDF file.

Coordinated by

. Estimated workload: 2 months. Read more...

Google Docs Integration

In 2007, an experimental Summer of Code project 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. Read more...

Google Wave integation

Find very nice ways to integrate Google Wave with XWiki:

  • embed Google Wave in XWiki
  • two way replication
  • support xwiki syntax in Google Wave

Coordinated by

. Estimated workload: 3 month. Read more...

Import and preview via Microsoft Office

Make the office importer module work with both OpenOffice and MS Office.

XWiki has the ability to import office documents into wiki pages using its office importer application. Additionally, inline documents preview is now under development. These solutions rely on an OpenOffice server installation which is driven by the JODConverter library. While the output of open office is mostly acceptable, the MS Office version is sometimes better. The task would be to extend the office importer module by allowing it to also use MS Office applications, not just the OpenOffice server.

Steps:

- define the Office Services, build a basic server module (on top of XOffice automation or as a separate service using the XOffice content management)
- consume the services trough the office importer/preview module[s]
- extend the office importer application UI with the new features.

Coordinated by

. Estimated workload: 3 months. Read more...

Import from any other Wiki

Create an extensible framework to import data from other wiki platforms. This should handle basic features:

  • converting basic formatting syntax
  • links between pages
  • document metadata
  • attachments
  • history

and, where applicable, more complex features, such as:

  • access rights
  • custom structured data
  • macros

The implementation should continue the work previously done during the 2009 GSoC. The basic flow is:

  • an export of the source wiki (obtained using the export feature of the source wiki) is parsed into a specific implementation of the importer data model
  • this model is converted into XWiki documents, according to the XWiki data model, taking care of proper syntax conversion
  • these documents are saved in the current wiki

The system should work at least for MediaWiki, Confluence and TWiki

Improved Bulletin Board Application

A basic bulletin board application was coded about 2 years ago. The project consists of improving the UI and general features of this application, better administration, better accessibility, better consistency with respect to the XWiki look and feel in general.

Coordinated by

. Estimated workload: 2 months. Read more...

LiveData Macro

A LiveTable Macro written in velocity and JavaScript was introduced in XWiki 1.9. Its most common use case is displaying a table of documents that contains an XWiki Object of a certain class, enriched with a live filtering feature.

The aim of this GSoC project is to extend and improve this component:

  • Make it a 2.0 wiki macro instead of a velocity macro (we're talking of a full re-design from scratch and a full rewrite)
  • Make it work "decently" without JavaScript -- at the moment, no data is displayed unless JavaScript is enabled
  • Allow other displays besides table: tree, free format rows...
  • Allow to edit the displayed data

Coordinated by           . Estimated workload: 3 months. Read more...

Macro support improvements

This project proposal is a draft. More macros need to be added to the list.

Add support for parameter types for wiki macros.

Reimplement existing Radeox and Velocity macros as 2.0 syntax macros:

  • IM Presence
  • image
  • jira
  • spoiler
  • twitter/identi.ca

Develop new macros:

  • author (document, lang, withLink)
  • creator (document, lang, withLink)
  • version (document, lang)
  • object display
  • children (doument, lang)
  • history (document, lang, withMinorEdits)
  • attachments (document, type, by, orderBy=name)
  • blog (space|global, number of posts, summary or content, categories)
  • recent changes (space, tags, number, type=all|comments|attachments...)
  • search
  • tabs (type=horizontal|vertical, {label: page})

See also:

Coordinated by

. Estimated workload: 3 months. Read more...

Member Directory Application

Build a flexible member directory, with a friendly and accessible UI, allowing to navigate users by various (custom defined) criteria.

Coordinated by           . Estimated workload: 3 month. Read more...

Mobile Skin for XWiki

Create a lightweight mobile skin for XWiki, or rather make the already existing colibri skin websafe for the mobile devices. Use W3C widgets to put the core files on the mobile phone so that you only need to download the data (save network traffic). See also:

Coordinated by

. Estimated workload: 3 months. Read more...

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 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); could be done automatically by reading EXIF information from the photos
  • 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.

In addition to the client side UI, some interesting features requiring platform changes would be:

  • uploading an archive that contains several photos, and automatically extract the photos from it (as opposed to uploading the photos one by one).
  • better tags implementation, allowing to tag attachments
  • better comment implementation, allowing to associate comments with an attachment

More modern features based on the upcoming HTML5 standard could be:

Coordinated by

. Estimated workload: 3 months. Read more...

Send Mail to Users

Based on the "Send Page By Email" Application, improve/extend the mechanism, allowing to e-mail different categories of users:
- all users having participated to a page
- users specifically asking to be notified automatically any time there is a change (separately from the XWiki Watch List).
- a group or all users in the Wiki.

Coordinated by           . Estimated workload: 2 month. Read more...

SocialCalc Integration

An experimental integration with SocialCalc has been done (XWiki Macro with JS launching and saving to the wiki document). This can be improved by converting SocialCalc content to Excel / Wiki Table syntax and package the macro in a nice format as well as nice skin integration.

Coordinated by           .  Read more...

Specific WikiMacro Editors

XWiki now has a very powerful WYSIWYG editor based on GWT which includes a wizard for inserting wiki macros (for example, for displaying message boxes, footnotes, mathematical formulas, etc).

This GSoC project consists of improving the macro editing mechanism, by allowing to use macro-specific WYSIWYG editors: a mathematical expression editor for the formula macro, a SVG editor for the svg macro, etc.

Coordinated by

. Estimated workload: 3 months. Read more...

Wiki Editor Improvements

XWiki now has a very powerful WYSIWYG editor based on GWT which includes wizards for inserting links, images, tables and wiki macros.

However, some users may prefer to use the Wiki editor, which allows to have full control over the source of the wiki page.

This GSoC project consists in redesigning and improving the Wiki editor, with the main purpose of enriching it with the aforementioned wizards, and of integrating a user friendly Wiki Syntax Help feature.

Coordinated by

. Estimated workload: 2 months. Read more...

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, and more and more governments are moving to ODF as the official document format, and OpenOffice as the office suite of choice.

An implementation was started last year as a GSoC project, and although functional, the UI had to be left in a rather unfriendly state because of the OpenOffice API limitations at the time.

The target features of XOO:

  • A wizard for connecting to an XWiki server, done. Needs a better UI and better storage of the credentials
  • A navigation panel for browsing the documents inside the wiki, done. Currently it is implemented as a floating dialog, should be a docking window.
  • Downloading and uploading attachments, done.
  • Editing attachments supported by OpenOffice, not done. To be implemented.
  • Editing wiki documents in OOWriter, done. The UI needs to be improved.
  • Creating new documents, done. The UI needs to be improved.
  • Support for macros, not done. To be implemented. This is the main missing feature of the application.

Coordinated by

. Estimated workload: 3 months. Read more...

Get Connected