[sugar] [PATCH] Journal able to use "open with" for activity bundles

[Benjamin M. Schwartz]

On Wed, 2008-06-11 at 12:11 -0400, Michael Stone wrote:
> On Wed, Jun 11, 2008 at 11:37:13AM -0400, Benjamin M. Schwartz wrote:
> 
> Cute. Incidental thought: is performing a translation an action?

Thank you.  No, I don't see it as an action, especially because I
imagine that the translation is performed lazily.  Translators provide a
menu of potential new objects, but an object is actually created only
when some other action (like opening a frame of video in Paint, or
sending it to a friend) demands it.

> Secondary thought: if translating is an action, then have we
> simply produced transient or instantaneous activities which have no GUI?

I very much think of these as "passive translators", in opposition to
"Activities".  I imagine that they are non-interactive, and their nature
is infrastructural, not creative.  If an Activity is something fun and
productive to do, a Translator is something so basic, like viewing the
contents of a directory, that one does not even notice that one is doing
it.

Ultimately, the key difference between these forms of computation is how
they are presented in the interface.

> To me, the interesting claim is that these "transient activities" (or
> translators, if you think they're different) should be able to advertise
> that they can turn types A into (potentially) B, C, and D.)

I imagine translators as being integrated tightly into the Journal,
rather than being independent programs.  Also, I'm not sure that they
need to advertise output types in advance. Instead, I think they should
advertise input types, and when invoked, provide a list of potential
output objects, including types.

>  (If we
> expect the activities to be able to read the user's data in order to
> state make this determination, then we have even greater incentive to
> implement the Bitfrost P_DOCUMENT_RO and P_NETWORK protections - they
> seem to be ideally suited to this use case.)

There is certainly a resemblance here.  I imagined that translators
would have no network access, and could only read the single object in
question.  They would not have write access until an output is
requested, at which time they may write a single object to a particular
location.

However, for a first pass, I am not concerned about allowing untrusted,
user-generated translators.  I am happy to simply leave them as part of
Glucose, running as trusted code.  Once we have the next-gen datastore
working, then we may worry about better exposing its parts.

--Ben