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 _______________________________________________ Sugar mailing list [email protected] http://lists.laptop.org/listinfo/sugar
