Monday, May 01, 2006
Occasionally Connected Computing
I found an old initiative from Intel called Occasionally Connected Computing (OCC) that concerned how to create applications that had intermittent connectivity and needed offline access. It looks like nothing came of the OCC initiative, but studying some of their patterns and design choices for a dojo.offline and dojo.sync package might be useful:
http://www.devx.com/intel/article/16081/
I need to study some more of this.
http://www.devx.com/intel/article/16081/
I need to study some more of this.
Comments:
Links to this post:
<< Home
Let me know if you find some more good information on the topic. I've been looking at various control revision systems (subversion, darcs, ...) to learn some of their insights, but no clear solution yet.
The message queue architecture seems the most general approach to the "occasionally connected" problem, but it has some challenges:
-how to consolidate the data cache and local message queue into a single view of the local state?
-how to do the synchronization from a user experience standpoint, eg. in the case of a merge conflict: do you resolve the conflict now or do you sync the whole queue then resolve?
-how to translate application events (eg. editting a wiki entry) into messages in the queue? Store diffs?
Post a Comment
The message queue architecture seems the most general approach to the "occasionally connected" problem, but it has some challenges:
-how to consolidate the data cache and local message queue into a single view of the local state?
-how to do the synchronization from a user experience standpoint, eg. in the case of a merge conflict: do you resolve the conflict now or do you sync the whole queue then resolve?
-how to translate application events (eg. editting a wiki entry) into messages in the queue? Store diffs?
Links to this post:
<< Home
Subscribe to Posts [Atom]
