31 July 2007
Tuesday July 31, 2007, 2pm EST, 2AM Taipei, on #olpc-content. add to agenda. to be present: paur, lauren, sj, mel, (kim?)
- setting a time for regular meetings
- quick report on Wikimania; any requests from SJ and Mel (who will not be sleeping, apparently)
- check-in to make sure we have an easy place for Taipei Jam contributors (& others) to upload content - Library Grid not the most friendly thing in the world at present
- touch base re hiring (specifically re PM and server developer)
have a lot of disk space; useful as supernodes; shouldn't be required in general for services to work
- weekly discussions of implementation
- currently: no readily accessibly crypto signing
- libraries: preshipped, modular components added by hand
working on this: Adir Abraham
- use cases: world at large
Who gets to write to the data store?
Some of this is still up in the air. Interesting use cases:
- an activity wants to store something to the data store that is public and sharable. How can the store something in the data store and tag it as sharable?
- There's currently a "share activity" / "collaborate" button that shares a current document. Implications need to be worked out.
- We need an indicator of 'state' -- whether one is working in a shared or private state at a given moment.
- mesh board (distributed craigslist) -- as soon as you 'share' or 'publish' a new announcment, it is stored as something shared.
- Can something on the level of the presence service offer distributed content or other pervasive services that store data using the tag and permission features of the data store? should there be something similar but separat with different security implications for scratch-type store and forwarding? (see below)
Store and forward : Whether or not you use store and forward, there are times when you want to communicate with someone who isn't online.
- Imagine sharing distributed content across a loosely connected network.
- Can this use scratch storage on the laptops? Or another 'directory' in the data store?
Asynchronous notification: We need a style guideline for notifying someone that things are happening related to their interests outside the scope of the current full-frame activity
- notify people when they get responses to their efforts in a particular arena (say, board postings, or shared items further edited by collaborators)
- this can also be useful for doing semi-persistent sharing of files and other assets across the mesh.
Activity-level daemons : There's no spec yet for defining user-level activity daemons, for something persistent.
- Does a data sharing service need to be at the presence level? If so, we may need to provide a UI for turning this on and off.
- Do we need sth like a python libevent dbus loop to allow cheap addition of persistent service daemons?