Re: Online Desktop, Tomboy, and user storage

[Havoc Pennington <hp redhat com>]

Hi,

John Stowers wrote:
> I tried to raise this point in my previous email. I dont think putting
> app specific logic on the server is all that scalable.

This really depends on the goal. The goal I'm working on is not to have 
a backup of all my private data synced among all my home directories, 
though I think that's a cool project too and people are welcome to use 
any part of online.gnome.org that's useful for that project.

What I'm interested in is unique new functionality enabled by a desktop 
that's a window to the Internet (vs. a desktop that is primarily a way 
to edit my private data). So for example, collaboration features are 
important, and web access is important.

A simple example with Tomboy, maybe you want to be able to say "share 
this note with John and Elizabeth" where John and Elizabeth are chosen 
from your social network. The "ACL" on the note is then set so only they 
can access it.

Then maybe I get real-time notification when either of them is looking 
at the note.

App-specific logic is required to make this kind of stuff go, and the 
app-specific logic is useful for Tomboy even if no other app ever has 
it, then useful for the second app to have it even if no third app ever 
has it, and so on, so the scalability to writing N apps doesn't matter 
much, it only has to scale to however many apps we actually want to work 
on that would actually benefit.

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

The online.gnome.org server pretty much already supports webdav, the 
only issues are the authentication-related ones I mentioned before. If 
that can be sorted out (it's mostly a client-side webdav library 
problem), then the server is ready to go, modulo whatever bugs we find.
We could also and perhaps should just set up Apache for this, or just 
require people to use their own server.

That's separate from what I'm talking about working on though. In my 
previous post I talked about the stuff in addition to sync:

http://mail.gnome.org/archives/desktop-devel-list/2007-August/msg00023.html

The server must have an application-specific data model, or it can't 
have any UI.

On the client side we're doing the same, Tomboy needs an 
application-specific data model to do its UI.

This doesn't preclude or rule out a WebDAV facade to the user's data, it 
just means that the server has to be able to use the data in its 
application logic, for example the server might need to be able to 
convert the data to some Java objects that it can work with. That means 
any generic data store will have to have the equivalent of 'schemas' - 
in a WebDAV context, a fixed location for the Tomboy files and knowledge 
of their file format, for example, would be the schema.

I am all for a private, "just a file tree" data store on a server with 
no application logic; we could have for example one desktop-wide place 
where you set "my private storage location" and GNOME apps could 
integrate with a shell account or webdav share or S3 account or whatever 
individual users might have in order to store data. As I mentioned, the 
online.gnome.org server even has some support for this already (though 
maybe we want to use Apache when possible). I think another task here is 
to have some defined way to split up the DAV tree among apps, so users 
don't have to manually configure a directory for each app to use.

AFAIK Tomboy already pretty much does the private file sync, other than 
the issue of global configuration for the whole desktop.

I'm not in any way "against" that functionality.

What I'm interested in trying out, though, is not the same functionality.

The user experience goal I have in mind involves the server 
understanding the data so it can have additional UI specific to the app.

The point is that this is not (from a user perspective) sync - from a 
user perspective, it's just "this web app and my desktop and perhaps 
some others' desktops share the same data" and _how_ the data is 
magically shared is completely up to us as programmers.

It seems to me that sync is involved in the implementation, but it is 
not 100% clear to me how it is yet. So that's one thing I was trying to 
sort out in the previous mail.

Another "twist" as we move beyond sync is that some of the data may be 
shared between users, potentially in complex and fine-grained ways. For 
example, my view on the Online Desktop Engine data model contains my 
friend network's names and photos, with instant change notification if 
they change them.

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

This may seem like a basic question, but I was trying to ask something 
lower-level, which is just: which bits of Tomboy code would be replaced 
or hooked into by Conduit?

Naively, I would expect that Conduit corresponds to the SyncManager in 
Tomboy, which is a piece of code I don't expect to touch at all. So it 
isn't clear to me how Tomboy using Conduit or not would relate to what 
I'm doing. It is probably clearer to you, because you've spent a lot 
more time in these codebases.

To sum up the mail here, one implementation requirement for the user 
experience I'd like to try is to keep an app-specific data model that's 
shared between server-side application logic and client-side application 
logic. But the larger goal is a particular user experience, syncing the 
data model is not an end in itself.

Havoc