Re: Online Desktop, Tomboy, and user storage

I'm coming late here, but lucky this discussion is dumb so I didn't miss much.

The "online desktop" should allow it's users to dump stuff into their
own personal WebDAV space.  This is useful for a million and one

Tomboy exports to WebDAV already.  Tomboy can export to a little
corner of an online desktop user's online WebDAV space tomorrow.

If you want Web-accessible notes, write a web service in whatever
language you want that parses the Tomboy DAV notes.

Congrats!  End of thread.


On 8/8/07, john carr unrouted co uk <john carr unrouted co uk> wrote:
> > 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
> that...
> >
> > 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
> John
> (Gaawd its 1am!)
> _______________________________________________
> desktop-devel-list mailing list
> desktop-devel-list gnome org

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