[Sugar-devel] [PATCH Sugar] Extend sugar-launch with more options
michael at laptop.org
Sun Jan 23 15:58:19 EST 2011
Here are some brief thoughts for you.
>>>> Any good reason to not include it? :)
@Martin: The gains sure seem to me to out-weigh the costs.
>>> Yes, there is: It encourages activity authors to start other activities
>>> from within their own activities, exactly like you're going to do.
@Sascha: Thereby affording a better learning experience than is available
>>> We shouldn't give them easy access to functionality that we already know
>>> will stop working in the future.
@Sascha: I'm not as sure as you are that this functionality will stop working
in the future. I am, however, considerably more sure that Martin's change would
be of educational value in the meantime.
>>> Sascha, responding to his recap of Martin's goal:
>>> Launching activities from within another activity won't work on
>>> Rainbow-enabled systems (by design).
Remember that the goal of Bitfrost is "to prevent software from doing bad
things" like "damaging the machine", "compromising privacy", "damaging the
user's data", "doing bad things to other people", and "impersonating the user",
all in the service of making computers that are better things to think with
than were previously available.
Given this background, what reason is there to prevent a Podcast activity from
using Browse to implement a publication and search UI while simultaneously
using Record to capture its recordings? The important point is just that
Podcast shouldn't be able to delete all my documents.
Similiarly, what reason is there to prevent Arithmetic from launching Wikipedia
through clickable links associated with each mathematical operation for which
Arithmetic implements puzzles? Again, there's no reason to prevent this useful
interoperation of software written by separate people. The real goal is just to
prevent Arithmetic from being turned into a spambot by the new "puzzle"
algorithm that Bernie shared with me.
>> Well, it is a common UI in other operating systems, so I would not
>> specifically call this out as poor from a UI stand point.
The fashion in which it is poor is that, in implementations to date, it gives
the operating system little or no information about what ambient authority the
human operator actually wants to delegate to the software being launched.
As a result, most of these other operating systems are widely regarded as being
utterly unsafe for use as platforms on which to try out unvetted code such as
might be produced by mischievous youngsters like the ones who grew up to be,
well, us. :)
>> There have been many long threads about this in the past, with folks wanting
>> to launch activities from each other (common case cited is having lesson
>> plan documents of some kind, that can launch the related activities as you
>> work through them).
@Gary: Please count me among them:
>> However, in the discussions I remember, all of them hit the issue of
>> breaching Rainbow and its desired security model.
@Gary: Rainbow is just a tool for setting up fences. It's up to the UI to
figure out, based on the user's actions, what fences need to be set up.
Currently, that part is what isn't working so well.
(...well, that and the fact that we have no trustworthy supervisors which which
to implement the fences.)
More information about the Sugar-devel