Re: Online Desktop, Tomboy, and user storage

[Havoc Pennington <hp redhat com>]

Hi,

john carr unrouted co uk wrote:
> I'm one of the Conduit developers and I'd just like to get your feelings
> on where Conduit and/or OpenSync fit in to this.

My short answer would be I don't know, and perhaps you can give us some 
good thoughts.

Tomboy offers a case study where we can look at this concretely, as 
discussed in the other posts in the thread. Here are some possible 
differences with the Conduit approach, though I don't necessarily 
understand all the aspects of Conduit:

 1) "just a data store" vs. "server understands the data"
    In Tomboy, I'm looking at hooking in as a Sync addin,
    which means implementing an interface that is specific
    to Tomboy notes, rather than implementing a data store.
    The rest of the thread already discussed why the
    server would want to understand the data, e.g. to
    provide a web UI.

 2) "your data is on each device, but explicitly sync-able"
    vs. "your data is online"
    This is a subtle point but leads to various different
    UI and implementation decisions, potentially.

 3) "configurable backends" vs. "online.gnome.org (or equivalent
    hosted by vendor or end user) plus existing web services like
    Google Calendar or del.icio.us"
    I see this as tied to the "just a data store" point; if you
    say there's required server-side logic, then you can't support any
    random means of storing data as a pluggable backend.

I'm not sure these approaches are always mutually exclusive, but they 
seem different in focus.

> I understand that you guys are heading the charge on this

Please don't think of it that way. I am diving in just to show that I 
think it's worth diving in. But if a bunch more people dive in (and 
better yet head the charge) I would love it.

> The Conduit Server was then to lead on to a Django, TurboGears or
> otherwise Python based web app for viewing (and editing) your data online.
> Hosting it was a problem for us but we were hoping to get interest from
> the distros on that front. Also, as quite a small python app it would have
> been (hopefully) VPS friendly. This is pretty much defunct with
> online.gnome.org, though I don't think I could run my own personal "gnome
> online" on my VPS :))

I would not think of it this way, either - online.gnome.org certainly 
does not do this stuff yet, and basically to make it do this stuff a web 
app still needs writing.

In other words online.gnome.org is just a resource. My ideal would be 
that it lets you do a server side for a new app by just adding some db 
tables and some html/css and some new http API calls.

The resource is that there's an account system, load balancer, mechanism 
for live connection to desktop apps, physical servers already set up, 
etc. - months of work can be saved, and one just has to write 
application-specific logic.

However, the app logic still needs writing. If you look at 
dogfood-online.gnome.org there is not much there yet!

I consider the online.gnome.org thing an experiment, maybe the best 
route turns out to be only talking to existing services like Google, 
maybe the best route turns out to be just data sync with no web UI 
written by the GNOME project, maybe the best route is various 
independent server-side apps written in various languages, I don't know.

I _think_ online.gnome.org is a good approach, but there are some hard 
parts, mostly on the organizational side rather than the technical side, 
as we figure out things like branding and paying for storage.

So for now my goal is to get a case study going, such as Tomboy.

Havoc