overstimulate

Taboo is missing a large feature: syncing. We have wanted to implement it since we started coding it. Lately I've thought a lot about the requirements for implementation.

I think the most important requirement is service reliability shouldn't affect non-syncing user interactions with the client. If the syncing service is unavailable, the user's experience should still be pleasant (although the user should probably be informed when they have changes that haven't been pushed to the service yet).

Another requirement is the cost of running the service should be low (with back of envelope costs I get a thousand active users per dollar per month). Addons.mozilla.org reports that we are about to break 20k Active Daily Users (note this doesn't mean they are active users of Taboo), and so I need to support the fraction of users that would use this feature without much cost. I need to make sure whatever algorithm we end up using isn't too expensive, but I have less worry here.

The burning question on my mind is what approach to syncing should I use? Smarts on the server or client? Does anyone know any papers which talk about approaches to syncing, including conflict resolution models (and their tradeoffs)?

I'd like to get an initial version of the syncing service done by the end of May, but it depends on finding a good solution that will scale and provide a good user experience.

Responses to "Taboo Syncing"

1. Fri, 02 May 2008 jakedahn says:
   Can't we just sync with del.icio.us? Or at least make that an option? In my opinion, having a separate deal would just complicate things for current users of different services.
2. Fri, 02 May 2008 Richard says:
   I'd seriously take a look at what Foxmarks is doing: their syncing is (usually) very quick and it seems to be similar to what you'd need.
3. Sun, 04 May 2008 Kamilion says:
   Personally, I like what Firefox3's been doing with the Bookmarks+History+Tags and SQLite. Plus, with the SQLite manager for Firefox, It's easy to tinker about in the internals: https://addons.mozilla.org/en-US/firefox/addon/5817 It would be relatively simple to sync/rsync .SQLite files as well, or just upload their contents in some form of object notation like YAML, JSON, or CSV. I'm still waiting for someone to build an extension that will marry Google Bookmarks with FF3's SQLite based bookmark+history+tags.
4. Thu, 08 May 2008 lawrence says:
   Taboo seems to identify the specific browser machine. Why not give us the ability to apply that id to any browser we use? This assumes you host the data. If you are putting the data on our local machine then tell us where and we can synch the folders using something like foldershare. I really like Taboo and am using it a lot. I think it would be helpful if you posted the following: 1. How many pages we can save. 2. How long you keep the images 3. Where you store the images - privacy issues Great jobs. Thanks
5. Sat, 10 May 2008 Tobu says:
   I think you could run an XMPP server with pubsub for the publish/subscribe part (a distributed Observer pattern). You could also consider APMQ, but I don't know much about it. There is a reconciliation problem that arises if a tab has been modified in two taboo clients, but the clients haven't been able to communicate (eg, due to client or server loss of connectivity). In this case, the clients will have kept some backlog of changes. Client 1 will send his changes (such as, from page A to page Z), then client 2 will send his changes (from page A to page Y), but they no longer apply because there is no page A. By page I really mean session data, to allow for the same URL opened in a number of tabs. Tabs are anonymous and content-addressed by the hash of their session data. Unlike the equivalent DVCS problem, this Change/Change problem can be automatically handled by Taboo in a safe way. Upon receiving the A->Y update that was published by client 2, and finding no page A (session data really) in its set of tabs, client 1 can simply open a new tab at that page. No data was lost, and opening a tab is a small cost. There is also a Change/Delete problem, but it can be handled the same way, by preferring opening new tabs to the loss of a page.
6. Sat, 10 May 2008 Tobu says:
   paragraphs for readability I think you could run an XMPP server with pubsub for the publish/subscribe part (a distributed Observer pattern). You could also consider APMQ, but I don't know much about it.
   There is a reconciliation problem that arises if a tab has been modified in two taboo clients, but the clients haven't been able to communicate (eg, due to client or server loss of connectivity). In this case, the clients will have kept some backlog of changes. Client 1 will send his changes (such as, from page A to page Z), then client 2 will send his changes (from page A to page Y), but they no longer apply because there is no page A. By page I really mean session data, to allow for the same URL opened in a number of tabs. Tabs are anonymous and content-addressed by the hash of their session data.
   Unlike the equivalent DVCS problem, this Change/Change problem can be automatically handled by Taboo in a safe way. Upon receiving the A->Y update that was published by client 2, and finding no page A (session data really) in its set of tabs, client 1 can simply open a new tab at that page. No data was lost, and opening a tab is a small cost.
   There is also a Change/Delete problem, but it can be handled the same way, by preferring opening new tabs to the loss of a page.

Leave a response