Hi,
[EMAIL PROTECTED] 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
_______________________________________________
desktop-devel-list mailing list
[email protected]
http://mail.gnome.org/mailman/listinfo/desktop-devel-list
