Google is hosting a Summer of Code again, and Daisy has been accepted as a qualifying open source project.

What does that mean? Well, if you are a student, and your proposal qualifies, and your contribution is considered worthwhile, then you can get paid to contribute to Daisy: 4500 US$, no less! You'll find much more information about the program in the Google SoC Student FAQ.

We will use this page to list some work area ideas. Please keep in mind that it is you - the student - who needs to file a proposal with Google SoC, so our list isn't exhaustive or limiting.

We advise candidates to register themselves on the mailing-list, to discuss their ideas. (see community page for details)

The SoC student registration page is available from here.

# Student requirements

The nice peeps of Drupal have posted a rather relevant list of student requirements which we'll copy over here. Make sure to properly inform yourself about the program!

1. You must not overbook yourself. Working on your Daisy project should be your main activity for the entire summer.
2. You must be willing to provide regular status reports (weekly or bi-weekly).
3. You will be expected to learn about source code control and open source collaboration tools (in Daisy's case, that's Subversion and mailing lists, mainly)

Furthermore, this page gives you some ideas about how to file a proposal with Daisy.

# Daisy SoC sightings

- Outerthought will be present at the TermiLan party of the nearby Ghent University (23-25 March) to advocate the GSOC program and advise students on their application.

# Previous Daisy SoC Projects

In 2006 Daisy ended up with two projects (and one drop out). See the results of those in our subversion repository.

- Tim Cranfield gave a first shot on the Detachment client.
- And Kostiantyn Sokolinskyi made a php integration.

# Suggested project ideas for 2007

## Daisy Google Goodies

- integrate with Google OneBox (search API)
- create a Google Sitemap extension

## ODF Integration

The Open Document Format is gaining much attention and a growing momentum in the (non Microsoft part of the) industry. Of course, by virtue of the integrated Apache Lucene, we are already properly indexing these files, but more could be done.
With the 2.x release of OpenOffice as the de facto open reference implementation there is also somewhat of a oss-project-bridge-crossing opportunity in seeking to implement more ODF support into Daisy.

The non limiting list of various ways to integrate looks like this:

- generartion of ODF as an alternative to PDF for each document in the repository
- ODF generating "publication type" for the daisy-books
- import of ODF documents, converting them into wiki-editable documents
- round-trip editing through open-office of these documents (which is not unlike the detachment idea in the end)

If you are interested in this project, you should:

- be ready to get deep into the ODF XML specification and work out how things could get mapped onto Daisy documents
- be proficient in XSLT and or Java/SAX to code the optimal conversions

## WebDAV and/or JSR170 access to the repository

Daisy has a fair number of unique selling points and has brought some innovative approaches into the CMS scene.

- our one 'bag' plus metadata approach
- our opoen ReST based XML/HTTP API allowing other language bindings
- a working SQL like query language
- the bundled wiki approach as a default solution for the common authoring issues
- the book publication and rendering
- ...

While thriving to be unique and setting us appart from competition it is however not a goal to isolate us from other movements and standards in the area of content management.

Two much cited standard ways to integrate with a content-repository to date are the WebDAV protocol and the Java Content Repository APi (aka JCR or JSR170)
Providing some way of mapping the nouns and verbs from these specifications to our own ReST based API is an interesting exercise that should lead to an optional service to be deployed and ran (in the case of WebDAV) or an actual API mapping component (in the case of JCR).

Mapping the implied hierarchy of these standards to the flat structure of the Daisy repository should be as flexible as the current navigation-tree editing.

If you are interested in this project, you should:

- be ready to get deep into the WebDAV and/or JCR specifications and our own ReST API on the other hand
- be a seasoned Java developer that knows his XML and Web API's

## HTML diff (compare) component

This project is a research-level project for an ambitious, self-motivated student.

### Background

The main content type used for textual content in Daisy is a subset of HTML which is also well-formed XML (technically, it's not XHTML since it's not in the XHTML namespace).

Much like a source code version control system, in Daisy a version history of documents is kept. Being able to compare the content of these versions is very useful. Currently the diffs shown in Daisy are based on the HTML source text (just try Page Action -> Versions in the menu on top of this page to see an example). It would be very nice to have graphical diffs instead, thus simply a HTML document with changes, additions and deletions marked (a bit like the change tracking in word processors).

### Project notes

- the project result should be a Java library which takes two HTML (well-formed XML) files as input and delivers one marked-up HTML file as result.
- this project is independent from Daisy, the student doesn't need to learn anything about Daisy. If the project succeeds successfully, Daisy developers will be happy to integrate it.
- the diff should work with the XML structure of the documents, not some simpler tokenization which might not interpret the document structure correctly.
- a good start point would probably be to investigate current products to see how they approach the problem.

## Daisy books enhancements

Daisy contains a book-publishing module, whose purpose is to publish nice "books" from Daisy documents in a variety of formats (currently HTML and PDF). The books are produced in batch, the result is a set of static files.

A variety of enhancements can be done to this module:

- producing OpenOffice Writer / ODF format (some overlap with the ODF proposal, but see next point)
- using the OpenOffice API to produce formats such as PDF or MS-Word.
- experiment with latest Apache FOP for PDF production
- for the HTML publication:

- fulltext search solution (various possibilities: e.g. produce a Lucene index during the book publication, relying on the presence of a server-side something to search the index, or even better produce an index which is loaded & searched by client-side javascript, so avoiding the need to have something server-side installed)
- enhance the presentation: e.g. show the table of contents on each page

- ...

## New commenting system

Daisy currently includes a very simple system to add comments to documents. There is lot of room for enhancement here.

Some ideas:

- allow to associate/attach comments with parts of the documents (e.g. individual paragraphs or headers). For a nice example, see here.
- allow threaded comments
- allow to edit comments afterwards
- translate links in comments to clickable text (e.g. "daisy:" and "http:" should be translated to links)

- or allow very simple richt-text (just pargraphs, bullets, links, bold, ... editor should load very fast)

- allow searching on comments (both searching in the content of comments, as well as identifiers for the query language to retrieve e.g. the number of comments a document has)
- allow comments by anonymous (guest) users, i.e. it should then be possible for commenters to leave name, email and url.
- ...

## Daisy *DE*tachment client

People coming from classic office environments are easily lured into the benefits of centralized content management by the ease of use of the daisy wysiwyg editor. Without losing a recognisable content authoring environment they are happy to find:

1. one centrally managed version of things
2. allowing easy collaboration
3. and a fully operational search

just to name a few.
The cost to pay for all of this however is that people always need to be online/connected to participate in the authoring-collaboration process.

One of the possible solutions to the offline authoring has been dubbed the Daisy Detachment and is assumed to work like this:

- from the repository a detachment is retrieved as a zip containing

- the part-content of course in bare format (and with known mimetype)
- additional metadata about the document (fields, versions, variants, ...)
- additional metadata about the repository server managing it
- possibly additional metadata about the doctype the document complies to
- possibly additional metadata about the kind of lock contained in this detachment

- during it's detached life this zip can be mailed over to anyone, and authored off-line through the 'detachment client'
- this client (registered to open on the daisy-detachment mimetype and/or file extension) should allow

- to visualize the mentioned metadata
- allow modifications to it (probably maintaining the original as well for optimistic locking support)
- spawn an appropriate content editor for the various parts that are first unzipped to some temp directory, and rezipped into the 'detachment' when the detachment-client is closed
- maybe check/revalidate the lock when online
- allow to 'save to the repository' when online
- could probably be launched/installed via java-webstart as part of the online daisy-wiki

If you are interested in this project, you should:

- know how to build decent Java Gui applications that can integrate with the most common desktop environments (the client itself is probably minimal and should thus not get in the way)
- be ready to get deep into the data-structure of the daisy-repository to decide what minimal part of the related data to a given document variant will allow a maximal set of tempting features

In the 2006 edition of GSoC a first stab at this client was created. The code however needs an overhoal and further completion:

- bring it up to date with the 2.0 version of the repository
- change to reuse the format (and code) from the import-export tool if applicable
- provide a better desktop integration experience for various platforms (windows, linux and Mac)
- get it into shape to be shipped with the next Daisy Release

## Integration of Daisy in non-Java environments.

In GSOC 2006 we had a student that created a PHP library.

Daisy has a language-neutral HTTP/XML-based API to access its stand-alone repository server.

Daisy has also (of course) a native Java API wich can work in-JVM or remotely (transparently communicating over the HTTP/XML API), as illustrated in this diagram. Currently most Daisy-API usage (that we are aware of) makes use of these Java APIs.

It would be interesting to integrate facilities for the publication of content stored in the Daisy repository in non-Java-environments. For example Ruby(-on-Rails), Python or Mono/.NET.

In the first place content publication facilities (i.e. retrieval only) would be interesting, but support for updating content would also be interesting.

You could start out by experimenting a little bit with doing HTTP calls, and some XSL-based (or whatever) styling in the target language of choice. However, the goal of this project should rather be the development of a library or framework which makes such things quick and simple to use. Probably some useful feedback about the usability of Daisy's HTTP-API will also evolve from this project.

For use with Mono or .NET, it would also be interesting if the existing repository client Java code could be run transparently on these VMs.

If you are interested in this project, you should:

- have knowledge about the target language of choice, since Daisy developers won't be able to help you much with that
- have knowledge about XML and related technologies (XML namespaces, XSL), and the APIs to process them in the selected language (or be willing to learn about them on your own)
- much Java knowledge is not really needed, since you could consider the repository server to be a black-box

## Expanding the administration section

In Daisy's administration section it is currently possible to administrer collections, users, document types, ACLs and so forth. However the web based administration is far from complete.

### Sites

A Daisy instance can have any number of sites. These sites typically have a homepage, navigation, skin, ... Currently administrators must have shell access to the hosting server to create and configure sites. Creating sites can be done by creating a number of directories and files or by calling a script which pretty much does the work for you. Typically when admins wish to modify sites they will edit xml files.

A nice addition to the administration frontend would be the administration of Daisy sites. Administrators should then be able to create update and delete sites. A basic implementation would be to allow the admins to edit settings found in the siteconf.xml and skinconf.xml. Should you finish this quickly and still feeling frisky then you might also have a shot at the faceted browser configurations found in the site. Each 'browser' if configured or defined by a single xml file. This file is used to specify which facets apply, what the default conditions are, which styling can be used, etc.

### Import/Export

Recently Daisy has been improved to be able to make exports and import documents from other repositories. Again administrators would need shell access to do the export and import actions.
Typically the administrator would want to be able to specify which documents would need to be exported/importend and with which options. If you are interested in what the current possibilities are have a look here or here.

If you are up for the task you'll be getting your hands dirty with

- Daisy wiki frontend.
- cocoon. The forms framework cforms to be more specific.
- xml, xsd and how to process them.

## Other ideas

- Ajax enhanced authoring environment (should be more then just graphical effects though) possibly evolving into a pure browser direct repository-client (which would involve bypassing much of the cocoon-side logic)
- Spellchecker support (on client and maybe even on server: JMS process listening to new submits?)
- Translation support (keeping in sync variants in different languages)
- Provide extra administration screens to make the complete toolset (import, export, site-init,...backup) accessible via the browser.
- Dojofication of the wiki frontend application.
- Database independence layer
- Extension for Web App Mixin / Form Builder & Custom Form Handling
- (yours here)

# The mentors

- Marc Portier
- Steven Noels
- Paul Focke
- Bruno Dumon

# For the Belgian students

## Daisy SoC sightings

Outerthought will be present at the TermiLan party of the nearby Ghent University (23-25 March) to advocate the GSOC program and advise students on their application.

## Flyer (click to enlarge)

# Previous Daisy SoC Projects

## 2006

In 2006 Daisy ended up with two projects (and one drop out). See the results of those in our subversion repository.

- Tim Cranfield gave a first shot on the Detachment client.
- And Kostiantyn Sokolinskyi made a PHP client library.