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

[BryanBerry]

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.

[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

[Eben]

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?

[cjb]

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?

[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.

[marco]

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.

[bemasc]

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.

[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?

[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.

2. 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.

2. 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.