TE
TechEcho
Home24h TopNewestBestAskShowJobs
GitHubTwitter
Home

TechEcho

A tech news platform built with Next.js, providing global tech news and discussions.

GitHubTwitter

Home

HomeNewestBestAskShowJobs

Resources

HackerNews APIOriginal HackerNewsNext.js

© 2025 TechEcho. All rights reserved.

The State of Things.app Sync, Part 1

19 pointsby btsover 14 years ago

6 comments

stevenweiover 14 years ago
Offline syncing is tough, but it's hardly an unsolved problem in the world of software. It's not even an unsolved problem in their specific market: syncing a todo list between the iPhone, iPad, and Mac OS X.<p>I'm not a Things user, but I'd be pretty annoyed if after two years the only thing they've said is "it's really hard" and the actual feature is still months away.<p>There are two major mistakes here:<p><pre><code> &#62; Before closing this article, I would like to offer a &#62; cursory glance of where we‘re at right now: We have &#62; created and deployed both server and client-side sync &#62; components. Both components are completely general and &#62; can be used for any application. They have been &#62; successfully tested using a special demo program. We are &#62; now in the process of integrating this technology into &#62; Things. </code></pre> This smacks of massive over-engineering to me. Cloud syncing is one of those problems where the type of data you are syncing significantly affects how you approach the problem. In my experience, generalized components are not very useful here, since you need to custom tailor the sync based on your specific use case anyway.<p>I suspect they're now going to run into problems while mapping their generalized solution to their use case. And since there is only one use case to support in the first place, it won't have accomplished much except wasting a bunch of time.<p><pre><code> &#62; Finally, we must consider scalability. Creating a &#62; solution for a few thousand users is one thing – creating &#62; a solution for millions of users is a different beast &#62; entirely. We have all experienced what happens when a web &#62; service is accessed by more people than it was designed &#62; for; at first, the service becomes slow, then it fails &#62; entirely. It has been our primary goal to create an &#62; architecture where scalability was not an afterthought, &#62; but rather built-in from the beginning. </code></pre> Do they actually have a million users to support? I doubt it, given the relatively high price tag of Things on the iPhone/iPad/Mac ($9.99/$19.99/$49.95). If they did, they would have several million dollars to throw at the problem. This certainly seems like a case of premature optimization.<p>Judging by the comments here (and in the original blog post), in the amount of time they've spent trying to build the perfect, scalable sync framework, they've hemorrhaged a vast portion of their customer base to other apps like OmniFocus (despite the fact that OmniFocus is significantly more expensive).
unfletchover 14 years ago
Too late for this ex-Things user, unfortunately. I waited for over a year before switching to OmniFocus. After buying licenses and climbing OF's relatively steep learning curve, I'm too invested to switch back.
foobarbazooover 14 years ago
Two years and all I got was this stupid blog post.
guywithabikeover 14 years ago
I and every Things user I know of has switched to (and love) OmniFocus. It has sync and works now, not months from now.
mantasover 14 years ago
I jumped the ship and switched to RTM for syncing alone.<p>Now I just type in shopping list on my laptop and when I come to grocery store, it's in my iPhone. Feels good man!
anthonysover 14 years ago
If anyone wants a Things license let me know. I'm out.