3 ms·
There wasn't much in the way of meat in that post, unless I missed it. As far as I understood, the problem with calandering is: - Synchronization: with potenti
by retube 16y ago
There wasn't much in the way of meat in that post, unless I missed it. As far as I understood, the problem with calandering is:
- Synchronization: with potentially gazillions of users on a single network you've got a timeliness problem: User A may look free to User B, so he books User B, but actually in the interim User C books User B, so there's a conflict. Given the graph-like nature of such a network (all nodes potentially linked to each other) such conflicts could quickly ripple through the system.
Sounds interesting, I wish the author had been a little more specific about the problems.
- Maro 16y agoI wouldn't think the cross-scheduling issue is actually a huge practical problem, as it requires fairly specific failure cases. OTOH if the users are disconnected, then you can't solve the problem anyhow, so you just write a consistency checker that runs while/after syncing and alerts users. I think the real problem is sheer engineering complexity: having to support a large number of input/output formats, protocols, devices, locales, languages, countries, timezones, platforms, legacy features, backward-compatibility, tools, etc. and making it all look good on the desktop, web and mobile app. I think the OP is saying if you multiply these together, then you're screwed, unless you're Microsoft or Google...
- retube 16y agoRight. That makes more sense. But none of these are CS issues - as you say they're engineering ones. Some self-healing conflict resolver otoh is probably closer to a cs problem.