Re: Online Desktop, Tomboy, and user storage

[john carr unrouted co uk]

Hi everyone

This is my third attempt at this e-mail - it's hard not to waffle or
repeat myself! It's getting late now so my English may have degraded into
nonsensical babble :D

The purpose of this e-mail is to consider Conduit as part of the Tomboy
case study. How can Conduit help deliver "Tomboy online". What benefits
does it bring, what disadvantages. What would be the architecture and so
forth.

Hopefully I will convince you that sync can be generic and that Conduit
doesn't care whether its dealing with a "data store" or something that
understands what that data is. That's really a separate issue completely
to Conduit and generic sync logic.

Conduit is really split in to several parts. Firstly we have a collection
of dataproviders. Dataproviders are the application specific parts. No one
likes having a common interface, that would be easy and boring, so DP's
map everyone's home grown API's onto an established baseline.

For easy reference, the basic API is:

  get_all() - return a list of UID's (think ls)
  get(uid) - returns an object
  put(uid, obj) - returns a uid
  delete(uid)

And object needs a unique id, an hash (so we can tell if its changed), and
data to sync! An hash could just be the last modified time or a
serial/revision number.

With this the next layer of Conduit can actually sync two DP's together.
It doesn't matter what they are, local or remote or a device. The
important thing is the format of the data. Now in some cases this means
conversion, but Tomboy Online can be built to use Tomboy's format
natively. So no format conversion.

We also provide some infrastructure for notifications. These allow a DP to
say "hey i've got new data to sync!!". DP's can be made available
dynamically... This means they appear in response to system events - be it
avahi or HAL. This is especially useful in sync GUIs but its available to
any app that cares over Dbus.

The Conduit GUI is really a "pretty thing" on top of our core code. If we
have a wizard to turn on "Tomboy Online" out of the box the user might not
even see the Conduit GUI.

Hopefully it should already be clear how this fits in with the online
tomboy notes:

 * We commit to enabling the automatic background sync feature, which in
the scheme of things is quite trivial. It's already partly implemented.
When thats done, the experience then becomes pretty darn seamless for the
user.

 * Tomboy remains pretty much unchanged (work to have change notifications
from tomboy are underway anyway - its something Sandy already offered to
implement for us).

 * Conduit gains a dataprovider plugin that can sync notes to
online.gnome.org through whatever protocol you suggest. This protocol will
have to update the Tomboy online data model from the server end.

(This may relate to (1) and (3) in your original e-mail. I must be missing
part of the ogo stack because I don't see a problem there. Somehow we need
to pass the data to the server - WebDAV, REST, direct database access. It
doesn't matter. But that doesn't mean that the server can't understand the
data. I can send it a file through WebDAV and it can be processed and
stored in a DB, or whatever suits the application. So i'm sure i must be
missing  your point when it comes to (1) and (3)?)

 * Hopefully the server API will use something like
http://brbx.com/orbited so that updates at the server end can appear
locally immediately. I could be wrong but I don't think (2a) is possible
with a PUSH feature like im suggesting here. (Though it is possible if
using Conduit).

 * For free, Evolution Memos can be put on Tomboy online. The same
codepaths allow devices to sync and peer 2 peer without needing separate
interfaces.

I think an important thing here is that some people won't want
online.gnome.org. Personally, i might be tempted to use Conduit to sync
them to an SSH account or a password protected area of a server I control.
By integrating Conduit people have that choice, and at the same time we
don't waste time on multiple sync implementations.

I'm not saying Conduit is perfect, but i'm sure people we've worked with
will back me up when I say that we will work to resolve any issues we
encounter.

In closing, I wanted to point out that Tomboy didn't implement its own
sync because of Tomboy specific logic. It implemented it's own sync
because it was highly desired by GNOME users and yet neither Conduit or
OpenSync are first class citizens in the GNOME desktop.. This made reuse
something of a no-no (this is documented online, and Sandy or Boyd..
correct me if I'm wrong there...)

Apologies if i've glossed over anything there. I'm trying to keep it
concise, and i've failed. I've already spent well over 3 hours on my
response :-) If something doesn't add up i've probably over-simplified
some aspect or completely forgotten about it. Tell me off and i'll try
again :-)

John C
( Sorry if i put you to sleep ;) )