[edit] Ideas for GSoC 2008

These ideas represent merely a starting point. Bongo, right now, can be improved specifically in a number of key areas:

• Contacts. Shared contacts at the moment are a pain for free software, and few clients agree on how to look up contacts.
• Synchronisation. There are some decent implementations of synchronisation software and protocols; it would be really useful to integrate one.
• Collaboration on the web. We have a number of ideas about how to collaborate on line; specifically, we want to move towards a point where you can collaborate freely with other people, whether or not they are Bongo users.

Many of the ideas below address some of the problems in these areas, but they shouldn't be seen as a fixed list of the only things we're interested in, just a beginning.

[edit] For people proposing ideas

Each project should have some standard information:

• what the specific outputs and objectives would be
• whether any work has already been done which can contribute to the project
• what skills would be necessary/desirable for the student to be able to complete the project
• how easy and important the project is, on a scale from 1-5 (1 being not very easy/not very important, 5 being very easy/important)
• who the mentor might be

At some point we probably should split out this information into a specific page per-project, to expand on the information here.

Ideas from 2007 are also still valid.

[edit] General Projects

These are things which Bongo could really use, but would be widely helpful outside of the Bongo project. These would suit someone who had experience of these libraries/etc. in general, and no knowledge of Bongo would be required.

[edit] libical replacement

Currently we use the libical library for reading/writing iCal files. However, it suffers from a number of problems: sketchy maintenance, memory leakage, potential buffer overflows. It has been forked a number of times over the years, and although it is embedded in a number of projects it is a painful code base to maintain.

For Bongo, iCal data is often likely to be external - it will come from outside sources. Such data should be treated as potentially harmful, and the current libical is not the best framework for such an approach.

What would be useful would be a library designed around a "proper" parsing framework, with strong guarantees to parsing safety, security and fault detection and handling.

Skills required: C language, iCal knowledge, building safe parsers.

Ease: 2/5 Importance: 1/5 Mentor: Alex

[edit] SQLite ORM

Bongo's use of SQLite is pretty straightforward and standard, but is complicated by the fact that a lot of code needs to be written to do things which should be easy, like caching queries, managing transactions and creating new queries.

In particular, common code patterns (such as reading a line out of a database, updating the data, and then re-saving the data) is time-consuming.

All these problems could be solved by using a code-generating ORM or ORM-like layer which takes a description of the database and creates a GObject-like API to the "objects" in the database, which handle all the details of actually reading and writing.

The emphasis should be on utility, not the notional "purity" of OO database access. It is about saving work creating code, trusting the code to be more correct, and effectively having a higher-level API into the database. Thought should be given to how programmer time can be saved, and what common patterns there are (or, could be) in SQLite consumers. More "academic" concerns, such as forming query builders from OO data relationships, are of less interest since SQL WHERE clauses are easily written - it's the mechanics of access which is the problem.

Skills required: Knowledge of SQL, the SQLite library, C language, OO.

Ease: 3/5 Importance: 5/5 Mentor: Alex

[edit] A Python library for parsing natural dates

Ruby has an excellent little library called Chronic which interprets English strings as dates. This is similar to the libcalcmd C library already integrated into Bongo.

Both these solutions suffer from one large problem from our point of view: they're neither multi-cultural nor multi-lingual. For example, the English phrase "Let's meet a fortnight tomorrow" is parsed as the day after today, not fifteen days' time.

Another substantial limitation is that they undertake to solve a problem exactly where often the answer will be ambiguous. For example, for some speakers "next Wednesday" may mean "Wednesday next week", or "the Wednesday after the one coming" - both answers could be correct. Similarly, Japanese has a concept of "jun" which represents one third of a month - an ambiguous time range. By limiting themselves to a single date/time answer, the libraries reduce their usefulness, since they could offer the user a range of options.

This would be a complex project to undertake, and certainly a student would have trouble completing a library which works for a single language, let alone several. This project should, therefore, take the approach of a prototype or research into how such functionality can be built.

Outputs could include a study of a variety of language and calendar systems, with implemented parsers which can extract key pieces of data and have some notion of "time/date grammar". It would also be useful to have some kind of representational system for date/times and ranges so that new parsers could be implemented and integrate into existing ones: for example, "Wednesday in Week 42" is a valid construct, and may be very useful for certain business users.

Skills: Students who have knowledge of different languages, and especially calendar systems, would be best suited. Knowledge of parsing and Python is obviously also a huge advantage ;)

Ease: 2/5 Important: 3/5 Mentor: ?Alex

[edit] Bongo-Specific Projects

These projects are Bongo-specific, and will be of much less use to other projects.

[edit] Make Bongo an OpenID provider and consumer

Bongo has an auth subsystem, and creating an OpenID provider from that would be extremely simple. This would allow Bongo users to use their Bongo address as a log-in elsewhere. This would be the first milestone of this project.

The second milestone is tougher: making Bongo an OpenID consumer. Primarily, this would involve altering the Bongo data store to recognise OpenID authentication tokens, and adding the ability to authenticate OpenID to the auth library.

Skills required: Python, C, OpenID.

Ease: 4/5 Importance: 4/5 Mentor: Lionel

[edit] Create "Getting Things Done"-type tools for Bongo Web UI

The GTD methodology is very popular, but their are few apps which provide tools for people using it - although there are various guides about how you can adapt the various features mail clients provide in order to do things according to GTD.

This project would identify a small number of key tools which would make using GTD methods a lot easier with Bongo, and then write them as plugins to our webmail system. The main difficulty with this project will be adapting to web UI which isn't yet finished, so the student involved will have a strong influence on the development of this important part of Bongo.

Skills required: GTD knowledge, Javascript, possibly some Python.

Ease: 4/5 Importance: 3/5 Mentor: Lionel

[edit] Renew the Bongo Python bindings

Bongo currently has extensive Python bindings which give applications direct access to the store and queue, and which cover the large proportion of Bongo functionality. However, they could be improved.

One problem is that they depend on Bongo's C libraries being available: there is no reason why these libraries couldn't be pure Python. This would give us the ability to package them separately, and release them separately, so that code for other projects could sensibly be written (sync. connectors, for example).

Another problem is that they are very line-oriented rather than event-oriented. This makes it virtually impossible to use the out-of-band messaging from the Bongo store (since the OOB messages come at times when the Python is expecting a different response). The API should be adjusted to be more Twisted-like.

A basic design and code for this API has already been completed, so the student will not be starting from ground zero. The student would also be expected to complete a test suite for the API.

Skills required: Python, knowledge of networking sockets, asynchronous programming

Ease: 5/5 Importance: 5/5 Mentor: Alex

[edit] Integrate a Jabber server

Instant messaging and e-mail messaging shouldn't be separate worlds; they should just be different sides of the same coin. In that vein, it would be interesting to see some possibilities of integrating an existing Jabber server into Bongo.

This should include using the Bongo authentication system (or some authentication system which both Bongo and the Jabber server can access), taking buddy information from the user's addressbook (and/or merging with the Jabber service), and storing records of conversations over IM in the user's store so that they are able to archive and search over previous IM conversations in the same way as they can e-mails (use case: you know you spoke to Bob about the product launch, so you search all your conversations with Bob. That turns up two e-mails and a follow-up IM conversation, giving you the complete view).

Additionally, it would be good to have a written document as an output, giving consideration to how the Jabber/IM concept of "Presence" could/should be integrated into Bongo, both at a user interface level and at a more technical level.

Skills required: knowledge of Jabber, preferably C for the Jabber server, and some Bongo store knowledge.

Ease: 4/5 Importance: 3/5 Mentor: Pat/Alex

[edit] CardDAV support for Bongo

CardDAV is the up-and-coming protocol to do server-side contacts read/write and sharing with other users. In many respects, it is very similar to CalDAV, so work on this project will probably mean that it isn't a ground-up project: the existing CalDAV code can be improved and adapted to provide CardDAV support.

We would agree the outputs up front in addition to a CardDAV server. These outputs may include:

• specific enhancements to the CalDAV system;
• a CardDAV test suite and/or exemplar CardDAV client;

Skills required: Python, knowledge of DAV, knowledge of the Bongo store

Ease: 3/5 Importance: 4/5 Mentor: Jonny