GSoC 2009 has been announced. Since I think it makes sense for the kauriproject to apply for some student-participation I'm creating this page to list possible ideas.
Short descriptions here for now, I propose to link down to more detailed descriptions and feature-sets as people see fit (eventually to be completed by the students themselves).
GSoC 2009 Homepage is here: http://socghop.appspot.com/
Currently the 'kauriproject' has applied, but is not yet accepted for participation in the project (decision: March 18).
Students will need to eventually register with Google to send in their application. However to get accepted they should know that their application will be evaluated by the assigned mentors from the kauriproject developer team. The prime criteria we will be using are:
So, we do expect candidates to
Likewise mentors need to register (see link above) with Google to indicate they are willing to assist the students in successfully completing their projects.
If you run into problems or have any questions, you are welcome on our discussion list.
See GSoC project idea: https client certification
See GSoC project idea: authentication methods
See GSoC project idea: improve Kauri Runtime classloading
Kauri includes quite a bit of javascript (mostly on top of jQuery) and kauri
based projects are likely to be including some more of that. Given the fact
that we build stuff with maven it would be nice to have extensive javascript
build-support through a maven plugin.
Currently we do use such a beast (see
http://mojo.codehaus.org/javascript-maven-tools/index.html) but are missing some
features (namely a JSLint syntax checking, a better integrated automated
tess-suite)
Additionally, providing our own plugin would also allow far better integration
and support for people that build their own js focussed modules.
Kauri provides a mechanism for flexible prototyping as a means to gather end-user feadback and complete scope and feature-sets at the early stage of a project. To really leverage this it would be nice if the shown prototype could be easily be discussed about in an operational "running prototype" context. For that we envision the development of a kauri module that allows discussing about pages under development.
So when end-users browse the prototype they could leave online some comments associated to the pages they're trying out.
Additionally it would be great if upfront designers could annotate their designs to clarify some parts, indicate which parts aren't ready yet, pose open questions or ask for choosing between certain alternatives.
A possible extension to this module (allowing comment-threads) this module could result in some more generic forum application.
With some twist another extension to this commenting could introduce
This would then result in a very generic linkbase system where links between
pages and comments/annotations are kept externally of the original pages.
Of course some technique should be added to allow some link-overlaying
visualising the external links on a certain page.
Expect to see all sort of cross-scripting issues and some pragmatics to get them resolved.
A generic module providing tools that allow other modules to
avoid/detect/remove spam entries on publicly open interaction pages.
Things comming to mind:
A module to post-process svg documents in various ways.
Allow to combine some /robots.txt on the top level based on various local descriptions per module.
Additionally some heuristics could be applied to propose sensible defaults for certain types of services in the system
Module to organize and publish polls and votings on certain subjects.
Supporting module to easily organize some user-bound (persistent) buffer of last-used (or last-buffered) items for later reference.
Tracking - Monitoring - Instrumentation.
This module should introduce a central Java-service that can be injected into
the other modules requesting so.
This service (via API) should then receive encoded 'events' in a predefined format: (name, source-reference, user, path, level, value)
By API and by configuration the service knows how to deal with each different 'named' event. Some of the things it could do is:
Additionally it should be possible to let the service 'publish' these statistics to pre-configured locations (URI PUT) at specified intervals.
An extension would be to provide an on-line view on these statistics.
Some additional form-control to consider:
web-link picker: a mini-browser popup starting with a google-search or address entry that will follow the current URI shown and allow inserting it in the form-input box coupled to the control.
entity-ref-picker: a similar thing but more database-oriented: allowing to select a reference to an object in a local database
page-anchor-picker: a way to select a specific node on a certain page, and store the reference in some format
image-xy: control to register (and visualize) the xy coordinates on some predefined 'img' input
A module that simplifies adding your kauriproject-site under Google-Analytics by:
