I personally use Dropbox + EncFS to synchronize my notebooks across multiple hosts, and it works quite well for me.
I'd be concerned about using something like Google Docs for a few reasons: How much of an old school set of "filesystem" semantics is supported by Google Docs? Can Collections have other Collections as children? How are unknown-format binary attachments handled? Can attachments be a child of a Collection or must they be a child of a Document? In Zim, an attachment is a child of a Folder in the filesystem backend and not linked bidirectionally to a containing text File. What's the latency like? How long does it take to scan the contents of a deep tree with 3 years worth of notes in it, to create a Zim index file? With Dropbox's full local cache of the data stored as real files, Zim does this seconds or less. Zim's rich text capabilties might not map cleanly and reversibly to Google Docs' (HTML-based?) rich text. Would we store Zim as plain text in a Docs Document and strip out any HTML formatting when reading back into Zim? Is there any precedent for this kind of thing? Are other PIM or notebook apps doing it? Do the API docs have anything to say about this use-case for Google Docs? All that having been said, if you have the skillz, by all means mock something up or write up a spec and lets explore it. Brendan Kidwell On Thu, Oct 13, 2011 at 5:29 AM, Roberto Suarez Soto <talkingxo...@gmail.com > wrote: > > just wondering: has anyone thought about using Google Docs as > backend to Zim? > > It seems it wouldn't be too hard: the API is well documented, and > Google Docs "collections" and "documents" are very similar to Zim's > directories and files. I'm not volunteering, but I'd be eager to betatest, > if someone dares to do it :-) >
_______________________________________________ Mailing list: https://launchpad.net/~zim-wiki Post to : email@example.com Unsubscribe : https://launchpad.net/~zim-wiki More help : https://help.launchpad.net/ListHelp