GoogleSummerOfCode2007
XWiki Projects
This page hosts project ideas for the Google Summer of Code 2007.
Topics:
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
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 SOC student 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 12th of April to 28th of May) 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!)
Selected Projects/Students
AJAX Interface Improvements by Evelina Slatineanu
The current skin was written with accessibility in mind, meaning that it works well without javascript.
The next step is to add AJAX functionality on top of the existing code, minimizing the number of page reloads, adding new sliding effect to the interface elements, etc.
Collaborative tools on top of xwiki by Cristina Boureanu
we need to define more precisely what we need.
Examples:
- Collaborative doodle drawings
- Instant messaging/chat
- Forum
- Collaborative UML editing
- Collaborative board games (maybe a general framework + some PoC-s)
Functional Test Suite by Catalin Hritcu
Building a functional test suite covering the most important features of XWiki. The tests will be fully automated, and will use the Selenium application built for this purpose. Since the Selenium application is still experimental, additional work will be needed on the testing framework itself. Finally, some parts of the XWiki interface (like the XYSIWYG editor) will have to be enhanced to allow easier testing.
Google Docs Integration by Radu Danciu
Allow the editing of XWiki tables using the Google Spreadsheet interface and calculate formulas found in the tables.
IDE Editor Integration by J.A.D.T Jayasuriya
Create a plugin/extension for Eclipse and/or IntelliJ IDEA so that it's possible to edit XWiki pages directly from the IDE, following the same principle used by TimTam. Actually it should be possible to reuse TimTam's source code and modify/enhance it for using with XWiki. It might also be easier to start from scratch though. The choice will be left to the volunteer. Basic features:
- edit a document
- save (documents can be left open and only saved later on, thus acting as an offline feature)
- rename
- delete
- add comment
Advanced features:
- grab a wiki site locally so that one can work offline
Storage Improvements by Artem Melentyev
There are various improvements needed for the way XWiki stores it's data. For example, we need to implement a recycle bin mechanism (XWIKI-543), keep document history in a separate table, increase the default size of some table fields, increase the maximum size of some properties, add support for minor edit and edit comment fields, etc.
XWiki Offline by Vandan Parikh
Based on the current work on XWiki P2P, package an XWiki Offline client installable and allowing to replicate an manage conflicts. It should be possible to bring multiple wikis on the road.
Other Proposed Projects
These projects haven't been selected for the SOC 2007 but if you're interested to work on them please contact us on the XWiki mailing list. 294 projects proposed in total.Application Wizard
Full AJAX (GWT) based Application Wizard. This should be an IDE like environement allow to create data oriented application from scratch on top of the XWiki Framework. It should allow to design the data model and the presentation page.
Gadgets Integration
Implement the Universal Widget API allowing to integrate NetVibes but also Google Gadgets into XWiki Panels or pages
Google Web Toolkit Wykiwyg Editor
Working on a 100% GWT Wykiwyg editor allowing to support the same features as the current XWiki TinyMCE based editor.
Unit tests for the conversion from HTML to Wiki syntax are required.
Interface Extension Points
Implement a mechanism for allowing XWiki Applications to alter the content of existing interface elements, like adding a new tab in the admin mode, or a new page in the global preferences, or new menu items.
The best solution so far is to use an Overlay class. Here's how it would work (inspired by the XUL model):
- an overlay object registers a piece of content that should be added inside a container, identified by an id.
- the added content can be inserter either at the start or at the end of the container, with an optional neighbor component (e.g.: inside #globalmenu, at the end, if possible before #watchmenuentry). If possible means that if that component exists, respect the required ordering, but if doesn't exist, don't fail.
- we provide two functions, onStartId and onEndId, which automatically detect what are the components that must be also added
- each application provides such overlay objects in a document inside the .xar archive
This makes it easy to extend some content, without actually modifying it, but requires massive changes in the existing template to replace <div id=..."> elements with onStartId() calls.
See also http://jira.xwiki.org/jira/browse/XWIKI-649 and http://jira.xwiki.org/jira/browse/XWIKI-650
Office Import
Allow importing Office documents into XWiki using the WYSIWYG editor. This entails converting them to proper wiki syntax (Word, Excel). For example importing an Excel document should generate proper wiki tables. This project should also allow viewing attached Office documents in view mode.
OpenOffice Plugin
Allow XWiki to interact with an OpenOffice backend service allowing to:
- convert XWiki documents to OpenOffice supported format
- convert OpenOffice documents to HTML or Wiki syntax
- run calculations and generate graphs from Wiki tables
SSO Support
We need any Single Sing On (SSO) support in XWiki. Standards: OpenID, SAML, Shibboleth, LID, inames.
- XWiki as SSO client
Possible to login in xwiki with SSO account.
- XWiki as SSO server
Provide SSO accounts in xwiki installation. For example openid: username.xwiki.com
We need research SSO systems to choose best, more commonly SSO framework.
More information: http://mail-archive.objectweb.org/xwiki-dev/2007-03/msg00169.html
Links:
http://openid.net/ http://shibboleth.internet2.edu/ http://en.wikipedia.org/wiki/SAML http://lid.netmesh.org/ http://en.wikipedia.org/wiki/Inames http://yadis.org/ http://federid.objectweb.org/ http://jira.xwiki.org/jira/browse/XWIKI-402
Skin wizard
There was the idea of making a XWiki.Skin class, containing some options for colors, margins, widths, and to generate the skin based on these variables. For example, there should have been a 'padding' property which should have been used for panels, menu, page content... It was working for a while in the 'xwiki10' skin. The skin is supposed to be customized (well, based on the same general layout) using a skin wizard.
Social Networking Functionalities
we need to have a generic way to create a social network based on xwiki.
functions :
- relation between user
- personal blog (already developed)
- shared document
- shared links
- ...
see Wikipedia
Subversion Integration
Make XWiki the best wiki for development projects. For this we need to have a seamless integration with Subversion so that project documentation can be stored along with source code in Subversion. It should be bi-directional (I can check in in Subversion and it'll show up in XWiki or I can edit in XWiki and I'll get it when I do a svn update).
WYSIWYG MathML Editor
Curriki needs a MathML Editor. We propose to build it using Google Web Toolkit and to be WYSIWYG. It should generate MathML and/or Latex
WebDAV API
Allow XWiki to be browsable and editable from a WebDAV interface.
The WebDAV interface should allow to edit Wiki documents as well as attach files.
WikiDraw: An Integrated Solution for Collaborative Development, Versioning, and Publishing of SVG
There are many situations in which an integrated solution for real-time, multi-user collaborative development, versioning, and online publishing of vector graphics would be invaluable. Any profession that must collaborate with a group on media that can be represented by vector graphics would benefit from such a tool. These may include graphic designers, architects, software engineers (for UML diagrams), as well as multimedia artists.
However, the context in which I really foresee this solution being used is in the development of open source software. It would be especially useful in this field because even though developers of open source software are often bound together by a common interest, they are just as often separated by thousands of kilometers. Therefore, a tool that would allow geographically-distant developers to easily collaborate on software architecture in real time would be invaluable.
There are many open-source applications that implement a subset of the functionalities described above, but there are none that comprise a complete solution. A complete solution could use portions of existing code to construct a Rich Internet Application (RIA), which could then be gracefully added, through a plugin, to XWiki. This RIA would allow a user to edit, and commit SVG images directly from his or her browser, as well as collaborate with other users on the same document in real time.
The RIA will use GLIPSGraffiti as its codebase. It will therefore be Java-based and will be built as an applet. The codebase will be modified to be truly collaborative. This will entail construction of both a text-based chat client, as well as an engine for sharing SVG. These collaborative functionalities will be built from scratch as an extension to the GLIPSGraffiti codebase, and will be based around the XMPP protocol. An algorithm will be derived to handle synchronization. Additionally, in order to reduce the RIA's initial load time, classes will be loaded dynamically over the Internet.
The original proposal is available here:
http://docs.google.com/Doc?id=ddrn5wx9_1034c4sqwk
Development progress is being tracked here:
The GLIPSGraffiti homepage can be found here:
WikiModel Integration
Integrate WikiModel into XWiki so that it can be used as the parser and rendering engine. The integration should enhance WikiModel so that XWiki's wiki syntax is supported and add the ability to add additional syntaxes easily. This should be proved by implementing the Creole syntax (or a subset of it if time is too short).
This integration should also include making the WYSIWYG Editor compatible and possibly implement migration tools for existing pages.
Wiki Words Dictionary
Using WikiWords and special syntax for links involves additional work and missing links.
List of existing pages should be used to discover links automatically.
As simpler/extended functionality, XWiki should recognize acronyms as WikiWords
Example: http://moinmoin.wikiwikiweb.de/GaGaParser?highlight=%28gaga%29
Flexible Authentication Integration
- Make authentication configurable using properties - currently LDAP and Wiki are hardcoded
- Implement fallback - if first authentication method fails, try next
- Integrate Windows domain authentication:
- using JAAS
- using Apache with mod_sspi in front
- Windows authentication on non-Windows platform
Note: LDAP with ActiveDirectory described on old.xwiki.org
