Opened 7 years ago

Last modified 6 years ago

#6958 new enhancement

Need to be able to launch locally installed activities from within browse

Reported by: BryanBerry Owned by: mstone
Priority: high Milestone: 9.1.0-cancelled
Component: sugar Version:
Keywords: 9.1.0:? Cc: mstone, martin.langhoff, tomeu, Eben, bemasc
Blocked By: Blocking:
Deployments affected: Action Needed: never set
Verified: no

Description

We need to be able to launch different activities from a web page. For example, In an html-based lesson plan we would like the student to be able to launch a relevant activity in EToys and later in the same lesson an python-based activity or something written in Flash.

This is a very important feature for us and likely for the other deployments.

All the teachers ask for lesson plans and some are creating their own. Their will always be activities be written in different languages and we need some kind of format to put different activities into a narrative context.

I believe there are issues w/ Rainbow regarding this.

Change History (9)

comment:1 Changed 7 years ago by BryanBerry

let me clarify, when you launch the activity it doesn't have to open up w/in browse. For the python-based activities this is obviously impossible

comment:2 Changed 7 years ago by Eben

  • Owner changed from Eben to mstone

What I would like to see here is a service (provided by rainbow) which allows activities to request system handling of a provided URI (which could be an activity_id, a bundle reference, a URL, etc.). This service would reveal a modal dialog presenting the child with options regarding how to handle the type, based on that type.

For instance, it could offer the options to view a link in any installed browsers, or save it to the Journal. It could offer the option to open an object with any supported activities, or keep it in the Journal. This a) gives the user direct control, which should be consistent with the security model, b) actually offers even more functionality, since a number of actions might be available, tailoring the behavior to the user's wishes, and c) provides a generic service which any activity can take advantage of....I could imagine writing up a lesson plan in Write if it adds support for this type of link.

Michael, can you comment on the feasibility of this type of approach? We've had related discussions to similar effect regarding the simple action of allowing activities to link to URLs. Can you see a broader service with the above functionality?

comment:3 Changed 6 years ago by marco

  • Keywords 9.1.0:? added
  • Milestone changed from Never Assigned to 9.1.0

comment:4 Changed 6 years ago by cjb

  • Action Needed set to never set

I thought this already worked. When you download something, you're given the option of "Open", which takes you to its journal page, and you're a click away from "Resume"-ing it with the default handler or an alternate.

Bryan, could you provide a specific use case that you've found not to work?

comment:5 Changed 6 years ago by BryanBerry

In many cases the activity will already be installed, so it shouldn't be downloaded. for example:

Algebra class

Equations are blah, blah

<a img="illustrations of equations" />

Exercise 1:
<a href="open Etoys">go to Etoys and build a model that implements the following equation</a>

Exercise 2:
<a href="open Pippy">write small program in pippy that implements the following</a>

I click, journal, resume, open activity will be fairly cumbersome in this instance. A simple dialogue box that asks if you want to open the activity or not or do something else, would be much more straightforward.

comment:6 Changed 6 years ago by marco

  • Cc Eben added

The last time we talked about something like this, I think the consensus was:

  • Need to add an activity launching service to the shell.
  • The shell would have to ask some kind of confirmation to the user.

comment:7 follow-up: Changed 6 years ago by bemasc

  • Cc bemasc added

I don't understand what the issue is. The system already supports this.

All you need to do is:

  1. Declare in your activity.info that mime_types = .... some-special/mime-type
  2. Serve up a file from your server with that mime type

When the user clicks on the link to download that file, it will download, and then the user will be directed to that file's detail entry in the Journal. The only launch option presented will be the Activity you're trying to launch, because of the unique mime type.

The file can be very small, even empty. If all the lesson data is already contained within the Activity, then the downloaded file can indicate which lesson or section should be launched. Alternatively, the downloaded file can contain the relevant lesson data.

It's up to you how to implement it, but this has been possible from the beginning.

comment:8 in reply to: ↑ 7 ; follow-up: Changed 6 years ago by bert

Replying to bemasc:

It's up to you how to implement it, but this has been possible from the beginning.

It's also awkward to use, and fills up the Journal with useless files. Why does the Journal have to be involved anyway? Why can't there be a less intrusive way to open another activity? What actual harm could there be in instructing Sugar to launch an already installed activity as if we had clicked the activity icon?

comment:9 in reply to: ↑ 8 Changed 6 years ago by bemasc

Replying to bert:

What actual harm could there be in instructing Sugar to launch an already installed activity as if we had clicked the activity icon?

There are a number of reasons why we cannot provide a simple direct-launch system that allows one activity instance to launch another without user intervention.

  1. Security

1a. Resource exhaustion attacks
Although it is not yet implemented, Bitfrost explicitly contains a number of protections designed to prevent Activities from crashing the system by using up memory, CPU, network bandwidth, etc. If Sugar provides an API for directly launching other activities, I can easily make a program that crashes the system by launching 1000 instances of Browse.

1b. Data revelation attacks
Our conception of Activities has long been that they are like blank canvases, and the interesting data is stored in the Journal. Thus, for example, it is totally uninteresting to spawn an instance of Read without any contents. What you want is to spawn an instance of Read, opening a specific ebook from the Datastore. If Activity A does not have access to datastore object D, then it may simply launch another instance of A in the mode of "resuming" D. This second instance might, for example, share D over the network.

1c. Privilege combining attacks
An activity that does not have permission to use the network may cause data to be sent over the network by repeatedly launching an activity that performs network communication on startup. This can even be used as as side-channel network communications mechanism, using Morse code or similar on the startup time of the secondary activity.

  1. Design problems

2a. Multiple versions
Our plans for future Sugar explicitly permit multiple distinct Activities to be installed under the same name. They may be distinguished by version, or by cryptographic identifiers. Conversely, there may be no Activity installed under a particular name, but several user-created variants under different names that are functionally similar. Only the user can decide which Activity merits opening at a given time.

2b. Surprise
If one activity instance can launch another at any time, this can create a very surprising situation for users, in which Activity instances are created out of nowhere, without any indication of who created them or why. It seems to me that part of the goal of the Sugar design is to provide a predictable, comfortable environment by preventing Activity authors from committing certain egregious crimes against usability.

Why can't there be a less intrusive way to open another activity?

I agree that the current state of affairs is suboptimal. I would say, "why can't there be a more convenient way to open another activity?". I would like to make two arguments:

  1. Based on the above issues, the user must be given an opportunity to explicitly confirm any Activity launch. This means that launching an Activity from Browse would require a minimum of two clicks. The user would click on an "open eToys" hyperlink, and then again in a Sugar-provided launch confirmation dialog.
  1. The method I have proposed, of downloading an appropriately typed file, requires three clicks: one on the hyperlink, one to switch to the file's Details page in the Journal once the download completes, and one on the "resume" button in the Journal.

If you would like to save the additional click, perhaps Browse could be patched to automatically bring up the Details page for any downloads from hyperlinks marked rel="autolaunch". This would save one click.

If you would like to save the creation of a datastore object, then perhaps the downloaded object should be "invisible", and be garbage-collected once both Activity instances close. However, given that every Activity instance is to be associated with a datastore object, I don't see this as a significant overhead. The downloaded object can also provide useful things like a default title for the instance and any other parameters.

Note: See TracTickets for help on using tickets.