Content meetings: Difference between revisions
Jump to navigation
Jump to search
(→July 5) |
(+notes) |
||
Line 33: | Line 33: | ||
* this can also be useful for doing semi-persistent sharing of files and other assets across the mesh. |
* 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? |
|||
[[Category:Content]] |
[[Category:Content]] |
Revision as of 19:51, 5 July 2007
see also talk:library, game development meetings, software meetings
school servers
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
content stamping
working on this: Adir Abraham
- use cases: world at large
data store
July 5
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.
Use cases:
- 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?