[sugar] sugar roadmap
Jameson "Chema" Quinn
jquinn at cs.oberlin.edu
Fri Apr 11 10:03:53 EDT 2008
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
More information about the Sugar
mailing list