[sugar] sugar roadmap

[Jameson "Chema" Quinn]

I'm assuming that the data would only go one way. In that case, the
permission would be, an app without P_NETWORK would not be able to request
opening of apps with P_NETWORK. No new permissions needed, just careful
attention to the ones we have.

On Fri, Apr 11, 2008 at 7:53 AM, Eben Eliason <eben.eliason at gmail.com>
wrote:

> 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
> _______________________________________________
> Sugar mailing list
> Sugar at lists.laptop.org
> http://lists.laptop.org/listinfo/sugar
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.laptop.org/pipermail/sugar/attachments/20080411/7606b3e5/attachment-0001.htm