[sugar] Multiple documents

[Bert Freudenberg]

Thank you Michael, this at least makes the security side more clear  
to me. A few comments interspersed below:

On Jul 27, 2007, at 22:13 , Michael Stone wrote:

> Now, to try to give the Security Team's perspective on the questions
> below:
>
>> The questions of how multiple activity instances are handled in Sugar
>> remains open. And even the way it is handled now is going to be
>> replaced "soon" with those security containers which from what I
>> heard yet appear to make it even harder to create efficient
>> solutions. In the earlier days of Sugar it appeared as if an activity
>> implementation would be allowed to manage its instances on its own.
>> Step by step this has been made harder. Now it appears to be required
>> that every instance is a separate process that starts and lives on
>> its own in its virtual container. Which is way inefficient, I
>> seriously hope I misunderstand intentions. But requests for detailed
>> plans have not been answered either.
>
> In philosophy, our design goal is to encourage activity designers  
> to use
> dynamic Activity instances running in separate containers to the
> extent that resource constraints allow because doing so enables us to
> statically provide better protection against viral documents, against
> data that crashes the activity instance, and against accidental
> breaches of privacy caused by inadequately fine collaboration
> granularity.
>
> In practice, however, we won't prevent activities from employing a
> factory scheme to better share resources at the expense of degrading
> our ability to provide the protections described above and at the
> additional conceivable expense of degrading the quality of the
> accounting statistics we are able to provide to the various resource
> consumption managers (e.g. disk quotas, OOM killer, etc)

So if an activity would like to handle multiple instances in one  
container or even one process, that would be fine. Great, this gives  
us some more options :)

> In the long run, we hope to do an end run around the issue by
> inventing a mechanism to share many resources across containers, by,
> for example, regarding containers as prototype-objects that can be
> descheduled (halting all processes inside the container), cloned
> (installing a lazy copy-on-write resource sharing strategy), and then
> rescheduled. Unfortunately, however, this is a research topic, not an
> implementation strategy.

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.

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?

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

>> And if so, what would one activity instance have to to do to create
>> a new instance?
>
> Instruct sugar to create a new instance, by using the API provided in
>
>   sugar/activity/activityfactory.py

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

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?

Thank you for taking the time and writing this up.

- Bert -