[sugar] Multiple documents

[Michael Stone]

On Sat, Jul 28, 2007 at 02:00:46AM +0200, Bert Freudenberg wrote:
> Thank you Michael, this at least makes the security side more clear  
> to me. 

Then it served its purpose. :)

> So if an activity would like to handle multiple instances in one  
> container or even one process, that would be fine. 

Exactly.

> Short of that ... I understand that system files (executables,  
> libraries, data files etc.) that an activity needs to access will be  
> shared between containers, that is, they are on disk only once and  
> are "projected" into the the container's virtual file system.

This is correct. Essentially, we call

mkdir /tmp/fizzle
mkdir /tmp/fizzle/bin
...
mount -o bind,ro /bin /tmp/fizzle/bin
mount -o bind,ro /usr /tmp/fizzle/bin
...
chroot /tmp/fizzle

The "island" is the contents of /tmp/fizzle, (which is, however,
slightly more complicated than my illustration would suggest).

> Say each instance of an activity loads a file into memory, and a  
> portion of this memory would not be written to. So copy-on-write  
> could be used on these memory pages between instances, meaning as  
> long as a page is not written to they would be shared an in memory  
> only once. What would an activity have to do to enable this sharing  
> of in memory file copies? I mean, without containers it could just  
> fork off new instances after loading the file. But maybe by just  
> mmapping the file would achieve the same across containers?

Not sure, though that would be really nice if correct. I'll add it to
our list of things to test. :)

> >> If I understand the Sugar philosophy correctly, we won't have
> >> multiple documents per activity. If we want to have multiple
> >> documents opened at the same time, these would be multiple instances
> >> of the same activity.
> >
> > Philosophically speaking, yes. In practice, however, its up to the
> > activity author and the datastore folks to negotiate what constitutes
> > a "document" (what I would call an 'Activity instance in the static
> > sense').
> >
> > Practically speaking, do keep in mind the requirements that Bitfrost
> > imposes on how the datastore and the filesystem may be accessed by
> > Activity instances in the dynamic sense.
> 
> ... like that it requires each file (datastore entry) only be opened  
> by a Sugar dialog.
> 
> For example - how could I make a slideshow of all images in the  
> datastore? Could an activity request this kind of "mass access"?

Two ways. First, there's P_DOCUMENT_RO, which, if requested at
installation time or otherwise granted by the user, allows the activity
read-only access to all the files of a given mime-type.

Also, if you have files that you *want* to store in the Datastore but
that aren't user-facing, we envision allocating a new mime-type for
those files that indicates that they are associated with your activity,
that they are generally "hidden", and that they may be accessed without
querying the user.

Of course neither of these things have been designed or implemented yet,
but that's at least roughly what we want to happen.

> Well, as long as an activity can provide its own factory that surely  
> is simple.

Indeed. Also, causing activity developers to use their own factory
explicitly helps us avoid some frustrating race conditions and therefore
allows us to give better feedback to the user about the status of their
activity launch.

> On a slightly related topic - supposed an activity went the "single- 
> process" way, handling all instances in one process (which given the  
> fullscreen nature of Sugar is not at all unreasonable IMHO), do you  
> see any reason to require a separate X window per instance?

I see no technical reason to require it, at the moment. The only place I
know that it matters is when we make the association between X windows
and security contexts required to prevent unauthorized activities from
interfering with unrelated activity's windows.

> Thank you for taking the time and writing this up.

It was long past overdue; I'm sorry it took us until now to work out
enough details to have something comprehensible to say!

In any case, please feel free to poke me again in the future if you want
me to make it a priority to write up an explanation of something for
you.

Michael