Re: Online Desktop, Tomboy, and user storage


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

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 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 launch we will be able to play
nicely immediately. Users will be able to use 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.


[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]