Re: Online Desktop, Tomboy, and user storage

["John Stowers" <john stowers lists gmail com>]

On 8/9/07, Havoc Pennington <hp redhat com> wrote:
> 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.

Conduit is already a case study in the common elements of
Synchronization over disparate services. Our data model has been
designed as such. It is a little lower level than what you are
describing.

The server should return a list of all the data.

Essentially, for each piece of data to be synchronized there must be
away to assign or associate a UID with that chunk of data. If possible
the server should provide methods to get the mtime and a hash of that
data without having to get the data itself.

Thats pretty much it, or at least allows Conduit to then work out
whats changed, been deleted, conflicts, etc. If the backend can
provide a GetDataThatsChanged(magicNumber) then it saves some
processing time, but this is not required, conduit can work without
this.

>
> 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"

I tried to raise this point in my previous email. I dont think putting
app specific logic on the server is all that scalable. I recognise
that tomboy is only a case study, and wanting the ability to edit and
view notes online necessitates a fair bit of server side code but to
have to implement this sort of thing for each "first class object" is
unwise.

I would like it if you provided a lowest common denominator interface.
The ability to get a list of object, to put and get objects, and to
associate metadata with these objects. It happens that using WebDAV is
an already workable way to do this, but if thats not suitable for you
then something else would need to be written.

>
>
> 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.

<snip tomboy sync architecture>

>
> 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)

We are familiar with the Tomboy implementation, as we are familiar
with the Sync implementations and abstractions of other projects. Our
data model has allowed us to extract the commonalities and work with
many different resources.

Basically, we already have a bunch of App specific logic in conduit.
If you want to go and implement some more app specific stuff to get a
good tomboy experience then that is your choice.

However, if you are able to implement something simpler for our
benefit then at the online.gnome.org launch we will be able to play
nicely immediately. Users will be able to use online.gnome.org to sync
things, and you can take advantage of out app specific logic.

John S

>
> Havoc
>
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org
> http://mail.gnome.org/mailman/listinfo/desktop-devel-list
>