"Red Westie", Copyright Ellery Armstrong, Milk Teeth Photography, Used With PermissionOn Monday we released Tomboy 0.15.1, the latest development release on the road to 1.0. It features a lot of the same fixes from 0.14.2, and some other improvements:
- Preview of new Web Synchronization add-in
- Work around problems on Windows caused by having multiple GTK+ applications modify PATH
- Search for phrases by surrounding them with quotes, save the width of the Notebook pane, and other improvements to the search UI
- Better HIG compliance in synchronization UIs
- All the same fixes from 0.14.2
- And much more!
I'd like to talk to you a little bit about this "Web Synchronization" add-in. From a feature perspective, the biggest problem with Tomboy has been how difficult it is to synchronize your notes between multiple computers, and to share your notes with your friends and colleagues. We have note synchronization but it's hard to set up unless you have your own server. You can share notes with Giver, but that has its limitations as well. And how do you view your notes when you're on a device without a Tomboy notes client?
A long time ago I blogged about how great a free "Tomboy Online" web service would be as a fix for these issues, but I never had the time to follow up on it. Until now.
Snowy, Your Tomboy Notes OnlineMeet Snowy. Snowy is a project started by Brad Taylor to bring your Tomboy notes online. It's "Tomboy's best friend on the web", as Brad says. Here is what you can expect from Snowy in the coming weeks and months:
- "Tomboy Online" - a free hosted service (running Snowy), where anybody can create an account for securely synchronizing their notes.
- Fine-grained privacy settings to let you mark your notes as public, private, or shared with specific friends.
- Edit your notes directly in your browser!
Editing notes in SnowyBrad started Snowy in his spare time, and recently our team at Novell had a Hackweek at our disposal. So last week, Brad and I decided to really get this project off the ground. It is still an extremely new project, but we feel it's far enough along to solicit feedback and contributions from the community. Some basic facts about the project:
- Snowy is AGPL-licensed. I firmly believe that our community needs to step up and start offering competitive AGPL web services. If we want to stay relevant, that is!
- Snowy is developed in Python on the Django web framework. Most people who expressed an interest in working on this were most familiar with Python for web apps.
- Snowy is developed in GNOME git. If you watch the commits list, you've no doubt seen the recent activity.
- Snowy is easy to deploy on your personal server. If you don't want to trust Tomboy Online with your notes, you can still use Snowy to give yourself web access to your notes, or just to provide a more convenient way to synchronize.
Snowy is brand new! I hope in the screenshots you see the potential, but I'm sure you also see how much room there is for improvement.
What works:
- Tomboy<->Snowy note synchronization
- Online note-viewing
- User registration
- Database administration and other fancy Django stuff
Logging in to SnowyWhere we need help:
- Authentication review, OAuth
- HTML/CSS/JS to prettify everything
- Design and implement all that cool note-sharing stuff
- Little features like copying a friend's note into your collection, or downloading/emailing/printing any note straight from your browser
- Security audit
- Your ideas!
You may be wondering how Snowy and Tomboy communicate for synchronization. I will talk about this more in a future post, but we have designed a REST API for web synchronization. This API is easy to consume from the client end, and easy to implement on the server end. This means we should have no trouble adding sync capabilities to Tomdroid and other Tomboy note clients. It also means that if you don't like Snowy, you can create your own web service that implements the same API, and still use the same web synchronization add-in included in Tomboy.
We still have a lot of work to do to make synchronizing and sharing your Tomboy notes effortless and fun! Outside of Snowy, here are some things we'd like help working on:
- Automatic background synchronization in Tomboy
- Web synchronization support in Tomdroid
- More features in the web synchronization add-in, like:
- One click to get from your Tomboy note to its Snowy page
- Control your sharing preferences for a note without opening your browser
- Easy access to friends' notes
- One click to get from your Tomboy note to its Snowy page
By the way, if you plan on using Tomboy 0.14.x for a long time, you'll be able to use the Web Synchronization add-in, too! When we launch Tomboy Online, downloads will be available for 0.14.x users on all platforms.
Stay tuned for more updates, and a demo server for everybody to play with!
This post brought to you by the Tomboy Blogposter add-in.
30 comments:
Team Tomboy AKA Team win :]
Well, is just what I´ve been waiting. I really miss a somekind of sync between my differents "tomboys". Great for all of you...
Sounds great! Amazing service! Cool feature. Can't wait.
AGPL FTW!
Will other Apps be allowed to use Snowy?
@Tom: Yup, any app will be able to interact with Snowy through the REST API.
If you mean can you sync other app data besides notes, well, that would be a much bigger project and it's not our focus right now. But we would love to hear your ideas!
This is completely amazing.
You know what would be even better? Also being able to use Tomboy Online to synchronise GTG or Labyrinth data.
That way you could have your notes, todo list and mindmaps globally available.
Will by there a possibility to add Tomboy note synchronization based on UbuntuOne? As onother optional service of course.
I dream about one service where i have my notes, list of contacts, important fioles etc as a backup.
Congrats on the launch of the project -- you guys rock. I hope this inspires more GNOME-headed folk to hack on FLOSS server (and desktop/server integration) projects.
AGPL and Django for the win! :-)
@User from Poland:
The UbuntuOne team is free to implement the same REST API that Snowy implements. Then you would just point to their server instead of ours, and everything would Just Work.
This sounds amazing... but, dies Snowy store synced notes in plain text? From what you write about concerns it sounds like this... Anyway, if so, consider storing notes encrypted similar to what Clipperz¹ did.
[1] http://www.clipperz.com/
@Anonymous: Encrypting user data could be cool, but it might require more server power than we can afford right now (decrypting data on every page view or note search, for example). If you have ideas for how to do it, help us spec it out!
That is awesome! I'll implement your REST API into Tomdroid to have sync between desktop and mobile. Yay!
long term... as more and more people experiment with fielding web services..integrated into the gnome desktop..its not going to make sense for every possible service to have its own API.
There is going to be a practical need to standardize what a Gnome web services API framework needs to look like, that can be re-used and extended in an organized fashion.
This isn't to knock the Tomboy API as it stands. But my concern is, if each and every application that could share information across the network built its own specialized API outside of a common framework, its going to be harder to consistently integrate and test each application specific service.
It's probably a little early, as there aren't many stakeholders yet in the desktop integrated open web services area, but at some point there is going to need to be some sort of consensus discussion on a web services API framework that needs to be held in the context of freedesktop.org.
Since you guys are out in front on this in terms of both open client and server code, you might be the ones to lead that sort of discussion when the time comes.
It would be great if you were already thinking about the Tomboy REST API as a subset of a more general API and built the supporting client and server support code for the more general case. That may help other application developers re-use your code as a starting point to enable their own webservices.
Could for example Tomboy sync and iFolder both be subsets of a common API that a corporate network admin could then choose to host a local collaboration server codebase that handles that common API, with tomboy and ifolder just being two specific types of application data products?
As new applications add capabilities if they all used a common API framework, wouldn't that reduce the complexity of what a local network collaboration server codebase would have to look like?
Ideally the common collaboration server wouldn't need to be updated at all as a new application inside the API framework came online. The admin would just have to register and allow the new data product. Client interfaces would then communicate with the server and manipulate the new data product. A web service interface specific for each data product would just be another type of client interface, using the common API to talk to the collaboration server where ever that actually is in the network.
Well anyways, its a thought.
-jef
Awesome, this is basically what my talk will be about at GUADEC. Hooking up apps to the web in interesting ways (pushing the AGPL while I'm at it). Will the service be up by July 3rd so I can use it as a demo in my talk?
I totally agree with (Ubuntu basher) Jef (to my surprise quite often lately).
This is something freedesktop should standardize. And while they are at it they should work on the KDE4 social desktop too.
The public data should implement the linked open data format Tim Berners-Lee talks about (TED talk).
So maybe Freedesktop isn't even big enough ;)
I guess this will mean some fairly large XML format. But the good thing about XML is that it degrades pretty gracefully.
get it right... I am a Canonical basher.
And on this particular point, if Canonical is committed to keeping their UbuntuOne services protocol open and extensible.. I'm actually a supporter.
There needs to be a framework in the space. Exactly what that framework looks like I can't say. Maybe Canonical's Ubunet protocols are absolutely perfect as the basis of a cross-desktop framework. I'm certainly not one to judge. But there needs to be a meeting of the minds on this who are committed to building a common framework on which to hang both open/closed client and open/closed server code.
If Canonical can commit to an open extensible framework built in part on consensus discussion and an implementation of a common reliable integrated cross-desktop component library to talk the language of that framework..that is something I can get behind regardless of whether or not they poop out open server code.
Extra points if you can get established proprietary web service vendors like flickr in on the discussion to and get them to adapt their offerings to support the common framework as well.
-jef
Snowy looks like Pownce that was also django powered. i guess it must be a coincidence. but maybe you should ask mike malone or leah culver herself for some help..maybe they get a kick out of helping.
but great project all around. will be fun to test it out and synchronize from windows to windows and from portable ubuntu for windows to windows. if only there was a suse project like that... :P
when will I be able to change the background color of a Tomboy note
If you look sidelong at that picture of a dog, it looks like he is baying for blood.
Anyway, awesome awesome news.
Folks, I'm out of town until Monday, sorry for the delay in getting back to ya'all.
@J5: I will be really disappointed if we don't have a live demo server before July! Really looking forward to chatting with you at GUADEC.
@Jef and @Tom: The design of all of this is very modular. We could change APIs or do any number of things without too much impact. But right now, we only have the resources to focus on dealing with Tomboy notes. I would love to see something like Online Desktop take hold in GNOME, though. Again, if you have ideas for the best way for us to proceed, we should talk about it. :-) I am concerned, though, that a generic REST API would not suit Tomboy's needs (notes are all connected, syncs should be transactional, etc). But I am new to this!
Thanks for all the feedback everybody.
Sandy:
Like I said, its probably too early to have the more general discussion. There is going to be a need for some diversified experimentation before a workable consensus approach can be had.
I'm certainly not suggesting people write up a paper specification that isn't grounded on real world experience. I just want to make sure the first round of really good experiments don't end up being a collection of unrelated pidgeonholes, each solving the same common problems but in different ways.
But I have to wonder, are there lessons from how something like Dbus is constructed that can apply to useful network-enabled application functionality like the tomboy/snowy interaction? I don't know, the right answer could be I'm smoking crack.
The next GUADEC is going to be an excellent opportunity to start the process of getting the right people to think about envisioning a framework on which to hang different application specific services as part of consistent desktop integration approach.
Snowy's appearance as a concrete example of open server side code is going to help focus such a discussion, whenever it happens.
-jef
Awesome.
I tried to do something similar when the paper mockup was released by sending my notes to a dokuwiki installation using conduit and having a plugin for dokuwiki which could read the Tomboy syntax. But it was buggy and pretty much read-only otherwise you had to edit the xml directly if you wanted to modify it online.
This really look much better and usable.
Seriously exciting stuff. Thanks for working on it, and releasing as AGPL!
I love this, but the REST API needs a bit of polish. This, for instance, is completely contradictory: "A PUT lets you update/add/delete notes in the collection".
To add, there's POST. To delete, there's DELETE. To add, there's PUT. Using PUT to delete is a security and design flaw. Have a look at RFC 5023 (Atom Publishing Protocol) for inspiration on how to deal with items and collections. To be honest, AtomPub could serve as a basis for this API quite directly without any or much need for extensions. Have you considered it?
@asbjornu You need to think of the PUT to user/notes as an update of the collection resource. I'll be writing about this more in the future, but because Tomboy notes are all potentially connected and dependent on each other, updates need to be done transactionally in *one* request. If I add a new note and it causes text in several notes to become links to that new note, I need all of those updates to succeed, or none of them.
So, at this point CRUD of individual note objects is not really supported. This is the least RESTful part of the API, but it is a necessity, as I hope you understand now.
@Sandy
You don't need server power to enjoy encrypted notes. Let's the user browsers do the work!
I'm the co-founder of Clipperz, the online password manager that is leveraging browser-based cryptography. If the Snowy team is interested in providing more privacy to their user they can consider using our Javascript Crypto Library. It's AGPL as well.
Marco
@Marco: That's a cool approach! We'll have to look into that. Thanks for the info.
@Sandy, that makes perfect sense. I agree it isn't following the REST spirit to the point, but explaining it like you do, it does make sense and it is RESTful enough, imo.
I do like the extensive use of URI's within the response, though. That's excellent design. It would be cool if a future version of the synch API could support (a subset of) AtomPub, nonetheless! :-)
Could you say something about how you plan to pay for the service? Meaning how can you offer this for free?
@Anonymous: If I can't afford it, I'll ask the Foundation or Novell or other companies or users for financial assistance. I don't anticipate it being as expensive as a microblogging or video-posting site.
@Fakeer We're hoping to launch Tomboy Online with GNOME 3.0, but I'm not going to make any promises.
Right now you can deploy your own Snowy server or use Ubuntu One.
Post a Comment