Re: Online Desktop, Tomboy, and user storage

[john carr unrouted co uk]

Some more thoughts, now that i've slept.

So currently the case study is for Tomboy syncing data to an OGO web notes
application with "first class" support for tomboy (i.e. not data loss due
to formatting getting stripped, and also making use of metadata from
Tomboy such as tags).

In this limited case study I have no problems with using Tomboys own sync.
Given Conduit's still somewhat an external entity it wouldn't make sense
for this case study.

However, what next? Safe to say the "Online Gnome" experience won't stop
at notes. I would expect that Contacts or Events would be the next logical
kinds of data that would be synced to the OGO platform, or maybe
Bookmarks.

I think it would be a little mad to implement a sync engine and conflict
resolution in Epiphany, Evolution, Firefox, Thunderbird, Sunbird or
whatever the user happened to be using. So while its outside Havoc's
initial case study this is surely exactly where Conduit steps in. We
provide desktop wide "sync smarts" for all these applications and OGO. Now
as I've said bookmarks are on their way. Evolution support for Contacts,
Events, Notes and Tasks is there. We will be supporting the OGO APIs.

(As an aside, It's worth saying that if the Facebook API wasn't
over-protective with contact data then Conduit would already implement the
"Joe changed his mobile number on Facebook and I want my address book
updating" use case. It would have taken about 10 minutes. And have worked
with Evolution, iPod address book, Gmail contacts, and would have worked
with new "contact" plugins in the future.)

So with that said, the support i'm asking for is for someone working on
OGO for things other than tomboy notes to say "yes, that sounds like a
reasonable approach.. when we get to these we'll help to evolve Conduit
for this instead of rolling our own". Does that sound reasonable?

Slight change in topic....

Now this morning I woke up. Maybe its only having 3 hours sleep, but I
started to wonder how Conduit's DataProvider model could be extended. I'm
not talking just about sync anymore.

The DataProvider model currently supports a change signal. This is fired
when any change is detected and says "hey, you might want to sync now".
Typically this signal comes from something like GnomeVFS telling it which
file changed (in the future, it will get a Note "blah" added signal from
Tomboy). This signal is a bit pants at the moment, but what if it was
actually fired and said "Data ABC was added", "Data DEF was removed"
(Giving the UID and event type at the least). Now rather than Conduit
blindly initializing a full sync it can just sync that single piece of
data! This is quite cool from a dev point of view, and excellent for
"always up to date". Eh, its even a win on power saving as we don't have
to do all the get_changes crap!

Now if an individual "conduit" has been unavailable for a while
(NetworkManager says no network, but now its back) then Conduit can issue
a get_changes type sync to fetch everything up to date.. Then use the new
signal to keep them up to date. Also think of a turbo charged version of
our current network sync, as soon as you edit a note it will appear
practically instantly on the other Tomboy instance (ok, ok it would have
anyway.. but watching your notes just appear on the 2nd machine is
exciting!! and it does save the get_changes over network wasting time).

Right now some of you are probably thinking, you're just boring me with an
implementation detail! But think about it, if we take this API and also
expose it over dbus suddenly apps built on Conduit aren't just about sync.
I'm going to presume for a minute that we can do "PUSH" from OGO. The
Conduit API could be used to set trivial watches, not just on OGO but any
dataprovider.

I'm trying to think of a simple example... How about notifications when
something of interest happens? Conduit might already have a "friends
photos" dataprovider that gets the change signals from OGO...

Or perhaps Gimmie and BigBoard could benefit. They can use get_all to get
the current status of various bits of data they are interested in and
listen on the changed signal to have their GUIs kept up to date. Depending
on how nice we can get the Conduit UI the code needed in any app to grab
and keep data up to date seems quite trivial? I suggest this as a way to
not have multiple implementations of the same basic access layer.

App's like cheese could directly enumerate available dataproviders to
figure out where photos can be pushed.

Does providing access to this part of our framework seem useful to anyone
besides me? :) Or do I need to catch up on my sleep!

> > My problem is just a general worry that more and more apps will go do the
> > "roll there own" path when Conduit could help, even in the case of Cheese
> > which is looking to add Flickr support.
>
> You have to be on people's radar so they're aware of what you offer. I have
> been following Conduit because I think it's cool and has a lot to offer the
> project, but I don't know how many other people have been following it. One
> point I'd raise about this is that Conduit is less visible to the community
> because it's hosted elsewhere.

At the moment we try to post on Planet GNOME from time to time, but we
don't want to build up too much hype. I don't want to offend anyone here..
We'd love to get on GNOME SVN+Bugzilla, but getting a mailing list took
months. So there were some concerns that I would be left unable to commit
for a long time (I think John S already has an SVN account?). John
suggested we could kick the request off and continue to use our current
SVN server until I can get an account, then merge. So point taken, and
moving over to GNOME hosting is certainly something that we are looking
into.

> This 'wall' stuff is a bit unfair, though I can understand why you raise
it.
> Your path to inclusion in one of the official suites is to propose it
during
> the release process. Simple as that. One way of attracting attention and
> getting things on the agenda is to propose stuff for inclusion even before
> it's likely to be accepted. Then the answer is likely to be "this is rad
but
> not ready yet" and then a project might become part of the defacto assumed
> future. :-)
>
> You're suggesting that being 'outside the wall' is like a state defined for
> Conduit that is outside your control. The truth is that you need to start
> climbing... or you can just walk through the gate. :-)

Looking back I did place Conduit as something of a victim. That was the
wrong thing to do, my defense is it was 2AM! We are certainly trying our
best to climb, and I hope things like our "Evolution and Tomboy syncing
over the network to another Evo+Tomboy" demo will get some people excited
of the potential. More importantly, I hope Conduit is on a desktop near
you soon :-) *Pokes John about proposal process*

> I wholeheartedly encourage you to put Conduit on GNOME's agenda. It's full
> of awesome.

IDK, To hear *the* Jeff Waugh say that makes me feel all warm and fuzzy
inside..

Well I need to get some work done before I fall asleep...

John C