Desktop email clients, and to a certain extent mobile native ones, can do this to a good enough approximation by changing one common setting.
Dropbox magic is all in the scripts and combination of the scripts with hosting, rsync etc.
Changing a setting is too much for many potential customers, but writing and/or maintaining an entire service all by yourself is qualitatively different.
Not really. Another instance of the principle that a purpose-built solution is often better than free ad-hoc scripts/nonstandard configuration that can do exactly the same thing.
And besides, this isn't "the same thing". I know of no MUA that offers the ability to sync only specified threads in realtime.
> Not really. Another instance of the principle that a purpose-built solution is often better than free ad-hoc scripts/nonstandard configuration that can do exactly the same thing.
As long as your needs remain constant and perfectly aligned with the purpose of the app. Which happens exactly never.
Flexible / configurable solutions have higher up-front costs but often turn out better overall - because they can be easily adapted as needs (and wants) change.
INB4 someone says that users are dumb - no, they aren't. The dumb thing is actually the predominant trend in our industry of making everything purpose-built and simpler than possible, which makes people no longer expect themselves to spend even 5 seconds of learning to master a tool.
...makes people no longer expect themselves to spend even 5 seconds of learning to master a tool.
I, too, lament the state of user education in the computing world, but you can't change what people want by giving them an alternative that's technically superior, yet more difficult to set up.
Again, I point to Dropbox. You can most of the way there with some simple scripts and coreutils, but for some reason, my gran wasn't using this until someone wrapped it up in a nice UI and abstracted the complexity away. For some reason, she uses the Gmail web client instead of Mutt, even though the latter is objectively faster and more productive. For some reason, she uses a feature phone instead of a smartphone, even though the latter is easy to use and can do so much more.
There's a lesson here, often lost on more technical audiences, and I think it's this: Time and interest is limited, and developers should respect user's time and preference more than they do now.
