TE
科技回声
首页24小时热榜最新最佳问答展示工作
GitHubTwitter
首页

科技回声

基于 Next.js 构建的科技新闻平台,提供全球科技新闻和讨论内容。

GitHubTwitter

首页

首页最新最佳问答展示工作

资源链接

HackerNews API原版 HackerNewsNext.js

© 2025 科技回声. 版权所有。

Things: The State of Sync Part 2

14 点作者 nickcharlton超过 14 年前

6 条评论

kondro超过 14 年前
Wow, I can't believe they haven't built a centralised solution and that they think web-based sync is slow because of all the disk accesses. I don't care how big their user-base is, they are still only storing tasks - not images or videos.<p>Client to authorative server sync seems to be the way to go to me… it doesn't have to be live (they could queue up the syncing asynchronously) and they could control whatever subscription model they decide to put in place for one of the most expensive task management apps in existence (especially when you buy a copy for your Mac, iPhone and iPad).<p>For example: Remember the Milk seems to have solved this problem without having a slow application, and they have a web-based version (the default) of their app to boot with more features than Things would have.<p>I think the problem is they approached the wrong 'web developers' when they asked for a synchronisation solution. I could easily see 5+ million users on a single, active DB server with under 64GB of RAM being able to hold a complete index set in memory and being able complete 10,000+ queries per second with communication occurring via a queueing product like RabbitMQ or ActiveMQ or a custom long-lived Java/NIO web server written in under a couple-hundred lines of code to keep connections open to 100's of thousands of devices simultaneously (<a href="http://blog.urbanairship.com/blog/2010/08/24/c500k-in-action-at-urban-airship/" rel="nofollow">http://blog.urbanairship.com/blog/2010/08/24/c500k-in-action...</a>).
评论 #2105728 未加载
swombat超过 14 年前
Suggestion: get a competent web developer on the team.<p>Problem solved.<p>The problem is far easier to resolve than they seem to think. I'm pretty sure that even with a million active users, you could run something like this on a few hundred dollars a month of AWS hardware at the most. Compare that to the two years of software engineering time they've wasted on this so far.
nickcharlton超过 14 年前
It seems to me to be a very bad business decision to decide to write a framework first, before delivering on your core product.<p>As the deadlines have ended up slipping, they have ended up with a set of very defensive posts about why they haven't yet delivered.<p>I don't see why you would jeopardize (that might be a bit of a strong word, but I'm sure they haven't done amazingly in sales in the last few months compared to what they had been) your business by attempting something far more complex when your product was already behind others in the marketplace.<p>There's no reason why they couldn't have gotten cloud syncing working just for them, then rolling out the code into a framework later on. That seems to be the smarter way to go about doing it - not writing a series of defensive posts saying that it's so hard.
评论 #2103797 未加载
schrototo超过 14 年前
"We ended up with detailed plans to create a JavaScript-based cross-platform data model framework with Git-inspired sync built in. This strategy required substantial portions of all versions of Things to be rewritten. It was clearly the most ambitious project we ever took on. Dissatisfied with our previous attempts, we didn’t want to settle with anything short of perfection."<p>Wow, this reads like a textbook case of over-engineering. I'd have thought that experienced developers like Cultured Code, with a shipping and successful product, would know a little bit better than that...<p>Seriously, in all this time, nobody ever thought of just hacking something together that's <i>good enough</i> until a better solution is found?
jorangreef超过 14 年前
Sync is harder than you think.<p>But see: <a href="http://en.wikipedia.org/wiki/Merkle_tree" rel="nofollow">http://en.wikipedia.org/wiki/Merkle_tree</a>
apl超过 14 年前
Unfortunate, really unfortunate, because the software is good. Back to org-mode and Dropbox then.