Talk:Memebrand

From OLPC
Revision as of 05:11, 13 December 2007 by Sj (talk | contribs) (..)
Jump to: navigation, search

use scenarios

basic uses

Publish permanently

  1. Finish writing a document D.
  2. Toggle Global publishing, verify connection to local server
    1. optional : explicitly ask for mirroring and propagation
  3. Power off laptop, never use it again
result: D should be available from local server and any other repository that trusts the author and wishes to mirror published works; for the foreseeable future. (see whitelist/blacklist scenario)

Whitelist and blacklist authors

  1. Compile local list of contributors with known good reputations
  2. Compile local list of sporadic contributors known as spammers or vandals
  3. Sign and publish lists globally; each repository can choose which lists to aggregate and republish as their guides for prioritizing what to mirror
result: limited range for publishing network abuse

Publish locally

  1. Write a doc E with two friends.
    From its inception, it is published to the three of you
  2. Toggle Neighborhood/Local publishing, verify connection to local server
  3. Power off all three laptops, none of you ever use them again
result: E remains available from the local server to anyone on the local net, but is not passed on to other servers or repositories, and is not published to people visiting the local server's IP from other regions.


tricky collabs, not yet supported

Ongoing publishing

  1. Turn global publishing ON; set default license parameters.
  2. Contribute to a dozen available projects. My contributions are now published as above, though the collab as a whole in each case may have a different envelope published/licensed status.
  3. Review contributions : to potentially add new unilateral licenses (for instance, I forgot that I was contributing LGPL material to a BSD project, and a CC-SA image to a PD text).

other tricky use cases

Publish, then change metadata : Once something is published, new metadata should result in a new version; perhaps a minor version indicated in a specific way.

Publish, then delete : this should be done in a soft way (suggesting deletion for mirrors and archives that care). If enforced or deleted automatically by the network (this seems like a bad idea, but I can think of rare instances where it is useful), an explicit "delete on request" flag must be sent out with the original work. Which is to say, if one publishes something without such a flag, not even a change of heart -- or a vandal spoofing one's identity -- can force those works to be deleted.


current implementation

As of ship.2, there is no way to publish materials locally within an XO network, short of a web service provided by a machine on the local network that can be contacted via the browser. A webserver and WSGI framework is being added to the builds to enable future development of such services.