On Tue, 2007-09-25 at 20:55 -0400, Michael Stone wrote: > Bert, > > On Wed, Sep 26, 2007 at 12:14:50AM +0200, Bert Freudenberg wrote: > > Hi Michael, > > > > To check my understanding I'll paraphrase - if an activity was > > granted the P_DOCUMENT cap then it can modify existing documents in > > the datastore, but it only ever gets access to them by explicit user > > interaction. The P_DOCUMENT_RO cap does not require user interaction, > > but only grants read-only access. Correct so far? > > Exactly right.
Hmm, say Record saved before closing one session entry plus some photographs and a video (each of these is a separate entry). If we resume the session entry, Record should be able to read also the other entries it saved, so it can show to the user the same state the activity was in before closing. We are storing an 'activity' property in every entry metadata with values like 'org.laptop.RecordActivity'. Shouldn't an activity be able to access all entries that were created by it without user interaction (other than clicking Resume in the journal)? We are also storing an 'activity_id' property that represents the session that is being resumed. All objects saved as products of that session should have this same activity_id. > > So ... P_DOCUMENT is independent from the saving of my activity > > instance in the datastore, I assume? But for now, there is only a > > single datastore API. Will that change? > > Any activity can ask the datastore to store anything. The datastore > might refuse, due to space limits, rate-limiting, ..., etc, but no hard > restrictions are placed on "keeps". Well... my impression is that limits like the amount of space one activity can take, or rate limiting the API calls belong more to the security framework. I think rainbow will need to do similar things when controlling access to resources other than the datastore, right? > I don't presently have much to say about what API this should have. > > > Also, does P_DOCUMENT imply I can create arbitrary datastore entries? > > P_DOCUMENT is needed for gaining write access to the "stream of history" > represented by an existing document. No special capability is needed for > making a new stream of history. And what about modifying one existing entry? > > Will the dialog support creation of new documents? > > Hopefully my previous comment makes this clear? > > > And P_DOCUMENT_RO restricts access to certain document types - could > > a multi-media authoring tool request more than one type (we'd like to > > be able to mix text/image/audio/video)? And according to the bitfrost > > spec this conflicts with supporting streaming media, correct? > > My feeling on the subject is that the P_DOCUMENT_RO API should accept a > fairly general query -- say a set of mime types, in the first pass -- > and that Rainbow will just modify the query and/or filter results as it > pleases before making them available to the requesting activity. There will be an API for _retrieving_ from the Datastore all videos in it? What will mean _retrieving_, copying all those files from internal storage to a fs area accessible by the activity? If this is a real copy, we could easily run out of space, and if not, will take a lot of cpu time, even more if jffs2 compression cannot be disabled. Or the idea is rather creating links in the activity's fs area so it can read but not write to those files? I'm not sure activities need this capability, can anyone propose some use cases? I'm going to start a new thread with the use cases that involve the DataStore from the activities point of view. Tomeu _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
