Re: Online Desktop, Tomboy, and user storage


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. " (or equivalent
    hosted by vendor or end user) plus existing web services like
    Google Calendar or"
    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, 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 - certainly does not do this stuff yet, and basically to make it do this stuff a web app still needs writing.

In other words 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 there is not much there yet!

I consider the 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_ 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.


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