[sugar] Sharing data between activities.

[Samuel Klein]

On 8/26/07, Bert Freudenberg <bert at freudenbergs.de> wrote:
>
> On Aug 24, 2007, at 1:25 , Marco Pesenti Gritti wrote:
>
> > On 8/24/07, Carlos Neves <cn at sueste.net> wrote:
> >> - The images bundled are art done by kids on the MaMaMedia site. They
> >> are examples and can be trimmed down considerably, but they are also
> >> reasons to be proud for the kids that did them, so I guess that if we
> >> can keep the whole bunch, we will.
> >
> > Installing a bunch of example images with the activity bundle sounds
> > like a really bad idea to me, given our space limitation

We want to be careful with our space, especially in the core systems
whose components are never to be swapped out.  When it comes to
activities, this should be seen as a constraint to focus artistry and
selection, not an absolute limitation.  We have more than enough space
to include a good set of examples with every activity.

> > (independently from the fact that you want them share between multiple
> > activities). Why don't we just make these available separately, as a
> > content bundle (.xol)? That way kids can install and uninstall these
> > when they want through the journal.

The idea is that these images should always be available when the
activity launches; either downloaded / available as part of its bundle
or already on the system.  'make available separately' doesn't capture
this dependency.

Content bundles are not currently meant to be bundles that hang around
waiting for Activities to use them.  They are a stopgap for bundles
that don't include their own executable, but are viewable in a
browser, until we work out a better unified bundle definition that
covers these different use cases.  A hack to get something like what
one might want here : browse to a content bundle with images, and
download each one individually; have the Journal automatically note
their mime-type, and make that available to activities requesting
same.  A similar hack that doesn't require the journal to efficiently
process thousands of files all the time: make directories of shared
media available (read-only) to all activities, and let at least signed
activities add their media to such directories.

> Well, this seems to ignore the major intention of delivering initial
> content on the system - getting the kids to learn by example. How
> should they know they have to install something before they can start
> learning?

Right.  It would be a mistake to imagine that an Activity is complete
as soon as
it compiles and passes functional tests.

> Clicking an icon and getting an empty document was one of the major
> problems Etoys had before the OLPC version. The current initial Etoys
> project (our "launch" screen with the 5 cloud buttons) at least
> presents a couple of choices, and links to other projects that
> demonstrate various parts of the system.

And it is a dramatic improvement, especially when people are playing
around on their own without a walkthrough.

> How would that be done if the examples have to be installed first?
> Even leaving aside the problem of security concerns forbidding direct
> linking to objects in the journal, how *do* we provide a seamless
> introduction?

The basic questions here have nothing to do with security.

There is thread convergence with Carla's recent thread on how to
provide a concise introduction to Etoys without a personal tutorial...
 Some combination of illustrative projects and explicit help files (or
an intro) is a start.  (I'm not sure in Etoys's case how to sequence
the different intros that are available.)

SJ