[sugar] Importing objects from journal

[Michael Stone]

On Wed, Sep 26, 2007 at 11:54:36AM +0200, Tomeu Vizoso wrote:
> 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.

Resuming from the Journal is supposed to immediately give the resumed
activity access to everything it needs. There's no security risk here
because know, directly from Sugar, exactly what the user is trying to
do.

How would you like to indicate to Rainbow what extra data-store-backed
files should be included in activity containers on startup?

> 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)?

An activity should never have the innate authority to read things from
the datastore or to over-write them. Instead, the *user* should grant an
activity the needed authority on a per-collection-of-things basis by
manipulating the Sugar interface (e.g. resuming an activity, selecting a
file to open). In terms of implementation, we wish to translate
measurements of the user's intent made by Sugar into suggestions to
Rainbow on what access to grant to an activity. 

Does this answer your question?

> 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.

Perhaps. Can you say more about why you think this?

> I think rainbow will need to do similar things when controlling access
> to resources other than the datastore, right?

While it needs to do conceptually similar things, the actual
implementation details are fairly different from resource to resource.

> > 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?

This is what I was trying to get at. You can be granted authority to
access a specific entry either because Sugar resumed you with access to
that entry (and just that entry), or because Sugar told Rainbow "the
user wants to manipulate Entry E with Activity A".

P_DOCUMENT is the name of the capability required for an activity to
*invite* the user to select a collection of documents to be modified by
that activity instance.

> 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?

The implementation that I envision would be something like:

"hard-link the selected files into an appropriate staging area, then
bind-mount (read only, or writable, as needed) that directory into the
activity's sandbox."

> I'm not sure activities need this capability, can anyone propose some
> use cases?

I'm not sure I understand this question.

> I'm going to start a new thread with the use cases that involve the
> DataStore from the activities point of view.

Great.

Michael