Tomboy is a note-taking application for the GNOME desktop. As such it is evolving as a replacement for the traditional 'sticky notes' applet and offers several advantages, including easy formatting and wiki-style links. But currently Tomboy notes are limited to one desktop. That means that users can't easily transfer their notes between different desktops (e.g. their home and work computer or their desktop and laptop PC) or publish their notes for other users.
This project is supposed to solve this problem. Using an abstraction of Tomboy's data storage format and system, an alternative system for storing notes in a central repository will be developed. This repository can then be accessed by Tomboy instances. Additionally a note publishing system will be developed. It will allow to publish selected notes either on a local network (using Zeroconf) or to web pages.
- Refactoring of the existing Tomboy code base to abstract the storage of notes.
- Development of a central note storage server; evaluation of possible integration with existing servers, like evolution-data-storage or iCal-based solutions
- Development of a note publishing framework; developement of example publishers via web/e-mail/zeroconf
- Development of a note import framework; import notes from Zeroconf or e-mail; evalute use of iCal and related formats
Work starts on June right after the project's acceptance. Each deliverable should take about three weeks. The latter two deliverables are flexible in their nature, meaning that features (like extra publishers) can be postponed under time pressure. I will work on this project full-time.
All refactorings and all new code will be supported with NUnit tests. While a 100% code coverage will not be achieved, at least the non-GUI parts will have extensive unit tests.
A new interface, INoteStore, is introduced. NoteStores are responsible for physically writing and loading notes. FileNoteStore will store and load notes the same way it works at the moment. MemoryNoteStore is a testing store that will be used for unit tests. Further NoteStores must be designed later on in the project.
There are two separate use cases that are interesting: Syncing two (or more) Tomboy instances (e.g. for disconnected operation or the home/work machine use case) and note publishing (mainly to push them to other users, but maybe also for collaboration). Syncing two or more Tomboy instances:
- The user selects the sync/import/... action. (From the right click menu of the applet/tray icon? Might have discoverability issues. Maybe we should get the input from the Usability list at some point about this.)
- Now a dialog opens that lists all auto-discovered (via Avahi) Tomboy services. The user selects one.
- In case the remote instance is not in the local network, the user selects the option "Connect to another computer" (or something similar). The user can now either choose to enter a host name (probably an URL is preferable) or select from a list of known hosts (URLs). (The URL/Host could either point to a running Tomboy instance or could be a "Tomboy instance finder server".)
- If the remote service requires some kind of authentication, authentication information is requested. (At the beginning this could be a simple dialog, later an integration with the GNOME Keyring Manager is certainly important.)
- All notes of the remote instance are imported, i.e. they are locally cached, but whenever they are changed, the changes are pushed back to the server. On the other hand if notes on the remote instance are added or changed, the changes are incorporated locally. The remote instance should probably be instructed to do the same thing with the local instance, i.e. import all notes from it, pushing changes back to the local instance.
In the future the synced instance is auto-detected and syncing takes place automatically. With this proposal both Tomboy instances basically become "one" for purposes of data storage. In disconnected mode or when the connection is interrupted, changes are made locally and are resynced when the connection is reestablished. Is this desired or should syncing always happen manually? While the latter option seems more "safe" to me, I think it is not very user friendly, since you need to remember to sync periodically and I hope I didn't forget to sync my laptop with my desktop before boarding for my 12h flight.
There are two issues that come to mind:
- Conflict resolution (one possible solution: "forking" a note, i.e. the copy becomes a real, stand-alone note, while a new "link" to the original note is created)
- What about syncing multiple Tomboy instances? Say A links to B and B links to C. Now an original note is produced on A and pushed to B. Does B push the note to C? Does B tell C: "Hey, go ask A about this and that note."? Doesn't C learn about that note at all? And what if C in turn sync with A?
Also there is some configuration necessary on the part of the server Tomboy instance as well: At least some means to set authentication tokens for instances wishing to sync. One possibility is that the instance that did not instantiate the sync pops up a question dialog: "Do you want to allow syncing." This has the disadvantage that the user must be present, so remote syncing (work/home) is not possible. It also allows for a kind of DoS attack: Ask an instance periodically to sync. The other alternative is specifying an authentication token (e.g. a password) beforehand.
Of course introducing note sharing has security implications: Who can read my notes, who can edit my notes? For Zeroconf shared notes I plan to go about this in about this order:
- All shared notes are publically readable. This of course means that Tomboy needs to gain the notion of "read-only notes". Such read-only notes can't be edited, but copies can be created, which can be edited at will.
Notes can be tagged using arbitrary strings, similar to how other desktop components gain tagging as well. Notes can now be shared by tag. E.g. you could tag some of your notes Foo Project and share all notes with that tag (additionally to sharing individual notes).
- Singly shared notes and shared note groups can require a password. The password is the same for all users that want to access a certain group, since we don't want to implement a complicated authentication system.
- Shared notes can be written to (if the user enables it). This requires more thought, since synchronization issues and offline caching must be considered. One possible scheme involves short-time locking: One tomboy instance is considered "authoritative" (most likely the instance on which the note was initially created). When this instance can't be reached, the note will be flagged as read-only (but can be copied locally and that local copy can then be edited). When the authoritative instance is reachable and a user begins to edit a note, a write-lock on that note will be acquired and regularily updated. The changes the user performs are submitted to the authoritative instance at regular intervals. If the user stops writing for a certain interval, the lock is automatically removed. (Either gracefully by the client instance or forcefully by the authoritative instance.)
We need to come up with a proper GUI for that stuff. Notes shared via a central server might need a slightly different scheme, although the GUI should probably try to unify this.
Please add your ideas here:
- (Dan Shoutis):
- First : sweet, this is an excellent project -- congratulations and thanks! A few things that would make this A++ for my uses:
- A documented protocol so existing wiki software could be adapted to act as a Tomboy backend.
- The ability to export / share only a subset of notes. (This would require the introduction of some sort of categorization or tagging system, I think.) (I don't want personal notes to get published on the work wiki!).
See the Tomboy section of wiki:SummerOfCode2006/Ideas for more ideas.