GNOME Bugzilla – Bug 629590
Provide useful export of user data
Last modified: 2010-12-23 11:59:32 UTC
If a user's computers all explode, and they want their data but don't want to install Tomboy to get it (for example), there should be an easy way to export their notes (and other data) from Snowy. Constructing OAuth'd REST API calls is not trivial stuff, so let's provide a link in the Preferences page that simply downloads a zipped-up JSON representation of all of their notes. Once we have other useful info (friends, etc), that should probably be included in the export as well. Other ideas welcome.
I'm probably wrong, but just want to know what's the reason why zipped-up XML is not considered? JSON is more better than XML? :)
JSON is smaller than XML, and easier to parse, and it is the format documented for our REST API. Any server that implements our REST API should easily be able to provide note data in JSON format.
If I'm using Tomboy Online on one computer, and I go to a new computer and wish to download all my notes to there, is it the same process?
@stormy: For that case, you should be able to just sync tomboy to tomboy online. All of your notes would be downloaded all magic-like and put into your local tomboy instance.
@Sandy: Do you want the ability to export / import individual notes / notebooks as well, or just something in the prefs to export everything? The latter would be simple by creating a piston handler to dump all Notes + NoteTags for that specific user. Import is out of scope for this bug, but if I work on export, I'm also going to work on some sort of import.
(In reply to comment #5) > @Sandy: Do you want the ability to export / import individual notes / notebooks > as well, or just something in the prefs to export everything? At this time I would say all notes. In fact, the JSON response you get when you hit /api/1.0/user/notes?include_notes=true would be perfect. > The latter would be simple by creating a piston handler to dump all Notes + > NoteTags for that specific user. There's no need to dump a format so specific to our data model. The above JSON is already well understood by Snowy, Tomboy, etc, making import easier to implement. I think we can get away with simply adding session-based authentication support to the existing piston NotesHandler, and linking directly to that API endpoint. Leon has a patch that should handle this: http://github.com/leonhandreke/snowy/commit/707cd5c7d5101b1700fb59276eeb715d50e5f7f9 Though I'd prefer that the SessionAuthentication class live in snowy/api/sessionauth.py or something like that, instead of being patched into piston. > Import is out of scope for this bug, but if I work on export, I'm also going to > work on some sort of import. Sure, sounds good. I'm not 100% sure what this feature would look like (would it be wipe+replace, or merge with existing data, or what?). It should probably have its own bug.
Created attachment 171071 [details] [review] Add support for session-based API access This patch works. I'm not happy with the definition of the challenge() method, but that's a pretty minor detail. It's cleaner than Leon's approach (linked in previous comment) because it does not add duplicate URLs. He must not have realized the multiauth feature was added in one of our piston bumps.
For clarification, this patch does not add any UI for API export...it just makes implementing that a bit easier.
Comment on attachment 171071 [details] [review] Add support for session-based API access This was pushed along with the initial html5 client in November.
Still need a patch for data export, though. :-)
Clever users can just hit /api/1.0/user/notes?include_notes=true and download the output (of course we have no import functionality for that JSON in Tomboy or Snowy, but patches for that would be trivial).
Just letting you know that I'm working on fixing this bug for Google Code-in, with exporting notes in different formats such as XML, YAML and tarballs.
I've forked Snowy on GitHub with the changes: https://github.com/rofflwaffls/snowy
Thanks Tony, your changes have been pushed for 0.6. Closing the bug.