[sugar] sugar roadmap

[Eben Eliason]

On Fri, Apr 11, 2008 at 9:45 AM, Benjamin M. Schwartz
<bmschwar at fas.harvard.edu> wrote:
> -----BEGIN PGP SIGNED MESSAGE-----
>  Hash: SHA1
>
>
>
>  Eben Eliason wrote:
>  |>  >  3. Need easy way to group links to activities, such as in a lesson
>  |>  >  plan.
>  |>  >
>  |>  >  Use Case:
>  |>  >  Kid reads through geometry tutorial and clicks on first activity
> which
>  |>  >  opens up Dr. Geo. After finishing w/ Dr. Geo he does some more
> reading
>  |>  >  in the tutorial and then clicks on a second link which opens up a
>  |>  >  related GCompris activity.
>  |>  >
>  |>  >  We need a way to launch different activities from within a graphical
>  |>  >  context, e.g. a tutorial. HTML is the most practical way to do this.
> I
>  |>  >  know there are issues w/ Rainbow and activities calling other
>  activities
>  |>  >  but this is very important to the learning process.
>  |>
>  |>  Interesting, would like to know what Eben thinks about it.
>  |
>  | This is an interesting idea, and one I don't really have a direct
>  | solution for, at present.  One potential option, and perhaps the most
>  | interesting, is also a fair bit of work.  It entails adding a bitfrost
>  | permission (does it already have one?) akin to P_EXEC or something
>  | similar, which allows an activity to make a request to the shell to
>  | launch another activity, passing it a URI (could be a file, could be a
>  | URL, etc) and having it ask the user to confirm the action.  With such
>  | an approach, any activity that wanted could embed links to other
>  | activities, or to web sites.  If we build this into the shell, and
>  | offer it as a permission, I don't believe that it will pose any
>  | security problems*.
>  |
>  | * I could be very wrong, though.
>
>  IMHO, the best solution is the one already used by Browse in the case of
>  PDF downloads.  The files are downloaded, and then the Journal is asked to
>  present the user with information about the item and the option to launch
>  it.  This is akin to how most modern browsers handle media files that will
>  launch outside the browser.  They present a window saying "You are
>  downloading a file of type "PDF".  Would you like to open it using
>  "Document Viewer"?"  They also offer a drop-down list of alternative
>  applications.
>
>  Letting the Journal handle all open requests improves usability, in my
>  view, by ensuring that the user can always postpone an opening action, or
>  choose an alternative handler.  I also think it improves security, by
>  avoiding a number of potential DoS, privilege escalation, and information
>  disclosure (e.g. #6837, #6838) problems.

In case I was unclear, that is just the kind of thing I was
suggesting.  I think that the shell should expose a "launcher"
service, which will do just the kinds of things you mention here.  The
UI would all be handled by the shell, not the activity making the
request. Perhaps if it's always done this way through the shell
service, we don't even need a permission.

- Eben