Distributed architecture: Difference between revisions

From OLPC
Jump to navigation Jump to search
(+stub)
 
m (...)
 
Line 14: Line 14:
* Consider an svn/rsync model with a db as a store, that you can browse offline and push back later. --nate
* Consider an svn/rsync model with a db as a store, that you can browse offline and push back later. --nate
* If other people are working on the same material, have a way to view diffs. Consider the mikawiki as a model for doing this to text.
* If other people are working on the same material, have a way to view diffs. Consider the mikawiki as a model for doing this to text.
*: There's an SVN/WebDav client that lets you drag & drop files --nate

Latest revision as of 00:02, 16 May 2007

Activity developers are encouraged to think in terms of distributed partially-connected design and replication. Consider how users who are only occasionally connected would interact with an activity, and what they would regularly do.

Replication, caching, discovery

  • Have a subset of a database available locally when disconnected
  • Have a subset available at a school when without an uplink
  • Distribute requests for objects so that even if your machine and someone else's machine are never online at the same time, you can share materials.

Examples

What can be learned from existing examples?

  • Lotus Notes did a good job of synchronizing partially connected databases.
  • Plone and similar CMSes have some of the pieces in place to handle distributed partially-connected environments

Discussion

  • Consider an svn/rsync model with a db as a store, that you can browse offline and push back later. --nate
  • If other people are working on the same material, have a way to view diffs. Consider the mikawiki as a model for doing this to text.
    There's an SVN/WebDav client that lets you drag & drop files --nate