Re: Online Desktop, Tomboy, and user storage

> Hi,
> john carr unrouted co uk wrote:
>>  * Tomboy remains pretty much unchanged (work to have change
>> notifications
>> from tomboy are underway anyway - its something Sandy already offered to
>> implement for us).
>>  * Conduit gains a dataprovider plugin that can sync notes to
>> through whatever protocol you suggest. This protocol
>> will
>> have to update the Tomboy online data model from the server end.
> If I understand this, right now I'm coding an implementation of Tomboy's
> SyncServer and in a Conduit future I would code a Conduit data provider
> plugin.
> I think which of those interfaces I write to has very little to do with
> what I'm talking about coding, right? Am I off base here?
> The only thing that affects me is whether I code to the SyncServer
> interface in Tomboy now or a comparable Conduit interface.
> For now from my perspective the answer is "whichever one Tomboy uses" -
> porting Tomboy to Conduit is a separate project from what I'm doing, I
> would think.

I think that is correct. Rather than a SyncServer you would implement a
DataProvider for Conduit to be able to talk to your server. And yes,
whether  or not we are officially blessed as official sync app for
GNOME... Conduit will support your interface ;)

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.

If Conduit had been inside the GNOME Wall for 2.20 then this discussion
wouldn't be happening, or it wouldn't be me crying "OMG, save Conduit!!".
Perhaps the solution there is to break out the whip and see if Conduit can
move inside the great wall?

>> I think an important thing here is that some people won't want
>> Personally, i might be tempted to use Conduit to sync
>> them to an SSH account or a password protected area of a server I
>> control.
> You're comparing apples to oranges. If the desktop has a feature to sync
> my private notes to a private directory, then that's cool and I'm all
> for it.

Somehow I forgot that Tomboy had SSH sync already. Damn. Forget I said

> I'm not working on that feature, though. What I'm working on primarily
> *is* the server-side Tomboy app.
> The only way I am looking at touching Tomboy itself is to have a sync
> plugin that happens to sync to this server-side app, *instead of* a
> private data store. The private ssh server is still a configurable choice.
> The two features aren't the same or somehow interchangeable, they are
> two different, mutually exclusive ways to store your Tomboy data with
> different advantages.

I do get that data store != web app - I think was among the
first DP's i touhced IIRC.

So Conduit has a dataprovider. Tomboy has a sync plugin too. That's fair
enough. As I said earlier, we are doomed to this kind of multiplicity-ness
as long as we are outside the wall :-(

>> By integrating Conduit people have that choice, and at the same time we
>> don't waste time on multiple sync implementations.
> Whether Tomboy uses Conduit is a separate issue from my project, and
> whether has a server-side app available, though, right?
> I mean, Tomboy already supports choosing your sync plugin. If we move
> the choice of sync plugin to Conduit, that's cool, but hasn't changed
> anything about the code I'd have to write.

I agree with you. But I am keen to see the interface kept simple...

I guess my problem is that we have OpenSync, we have Conduit, we have
Tomboy. 3 separate syncing engines. My original e-mail was really aimed at
seeing where we fit in. Is there room for 3 ways of syncing on one
desktop? We are already working to make it 2 by working with the opensync
people. Tomboy can't depend our code though :-(

> The situation in Tomboy today, or with Conduit, is that you can sync it
> to a private DAV/ssh filesystem. And what I'm looking to add is that you
> could also sync it with a web app that knows specifically about Tomboy,
> if you choose to do so.

The situation in Tomboy today is that you can sync to a DAV/ssh/fuse
filesystem, and that you are going to add support for OGO.

The situation in Conduit is that you can sync to GnomeVFS,
(a web app not too far removed from (i imagine) the first few phases of
your project), iPod Notes, Evolution Memos or any instance of Tomboy or
Evolution Memos on another PC on your LAN using the avahi/xmlrpc stuff.

And we are going to implement the OGO API as well. In a different language :D


(Gaawd its 1am!)

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