Re: Online Desktop, Tomboy, and user storage

[Havoc Pennington <hp redhat com>]

Hi,

Tomboy offers a concrete case study about the various ways to store 
stuff on the server and set up the data model in the app.

I considered three places to hook in the server side.

1) Application "model" API - Tomboy has a nice architecture with a 
NoteManager object that has methods like:

   Note Create(string title);
   Note Find(string title);
   void Delete(Note note);

So you could just replace NoteManager, which has some API that assumes 
local files right now, but that looks like it would be moderately easy 
to remove. We could call this a "model addin" or "storage addin"


2) Sync addin API - in effect, this is "copy the app model to another 
app model" or "copy the app model from another app model," with some 
potential for a merge if both have changed. The addin interface has the 
methods to do that transactionally.


3) A data store for the existing filesystem-based sync addin, e.g. a 
WebDAV repository.


Summarizing the three models:


1)  [ App Data Model Interface ] backended by [ Server Side Data Model ]

2)  [ App Data Model Interface ] backended by [ Local Files ]
                                 synced to [ Server Side Data Model ]

3)  [ App Data Model Interface ] backended by [ Local Files ]
                                 synced to [ Files-Based Data Model ]
                                 backended by [ Server Side File Model ]


In both 1) and 2) the work involved is mostly to implement the "model" 
functions (create, find, delete, save notes).

I consider 3) just a sort of roundabout way to implement 2), so let's 
ignore 3) for the rest of this mail and consider it a possible 
implementation of 2).

2) can be an implementation of two different user experiences.

2)a) is "implicit" mode. The app automatically syncs to/from the server 
side in the background, whenever it's online. It only bothers the user
if there's some weird situation it can't sort out.

2)b) is "explicit" mode. The user has to press the Synchronize button.

In version 1), there may be an offline mode. If the offline mode allows 
editing while offline, I would think 1) ends up being in effect the same 
as 2)a).

I would say 1) and 2)a) are my favorite user experience.

Getting back to Tomboy concretely, the big reason I'm first going to try 
hooking in to the Sync addin interface, rather than the NoteManager 
interface, is that I think the sync is application-specific.

That is, if sync could be done generically in the Online Desktop Engine 
data model, then Tomboy could just use that data model and it would work 
offline also.

However, I'm betting the ODE can only support "read-only" ("cache 
stuff") offline mode in a generic way. So if an app wants to use ODE as 
its only data model, when offline it would be read-only or just disabled 
(which is 100% fine for certain cases, however I think not for Tomboy).

Since Tomboy wants to be read-write while offline, we need code in 
Tomboy to sync one repository of notes to another one, using 
Tomboy-specific logic.

That means we need it to look like 2) -

2)  [ App Data Model Interface ] backended by [ Local Files ]
                                 synced to [ Server Side Data Model ]

Where "synced to" is application-specific code that Tomboy already has, 
to go from the NoteManager to the sync addin interface.

For an app that can be read-only while offline, or has fairly simple 
sync that we can figure out how to handle generically in the ODE offline 
stuff perhaps, then maybe 1) makes sense:

1)  [ App Data Model Interface ] backended by [ Server Side Data Model ]

Perhaps talking about where Conduit would be involved in this concrete 
Tomboy scenario would help figure out how Conduit relates (look at 
NoteManager.cs, Synchronization/SyncManager.cs:SyncServer, 
Synchronization/FileSystemSyncServer.cs for the code I've been talking 
about in this mail)

Havoc