[sugar] Importing objects from journal

[Tomeu Vizoso]

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