[IAEP] (Ab)using the Journal for stuff that the user didn't do, create, or access

[Daniel Drake]

2009/8/11 Tomeu Vizoso <tomeu at sugarlabs.org>:
>>> You mean that you cannot open that library bundle by clicking on its
>>> journal entry?
>>
>> Correct me if I'm wrong, but none of the methods that could be used by
>> deployments to distribute materials this way in mass would result in a
>> journal entry appearing for their users. These methods are installing
>> through a package into /usr/whatever/library or unzipping into
>> ~/Library.
>
> Didn't thought about pushed updates, can they execute post-install
> scripts? If so, they could use copy-to-journal.

This only works when there is a journal created, so deployers would
have to hook into the exact moment after the user types in their name
and chooses colours as this is the earliest time when the journal is
created. Doesn't sound sensible.

This also wastes disk space as it results in 1 copy of the library
bundle in the journal, and another copy uncompressed on disk.

And am I the only one who feels like this is a role for the Sugar
shell and not for the journal? I've seen this kind of Journal-based
solution proposed for a couple of problems now, and I'm not keen on
it.

At least until this point, the journal has been for recording what the
user has done, created, or accessed. With this kind of approach, we'd
now be going into classrooms asking users to look for something in
their journal which they've never seen before, and has never been a
part of their interactions.

I much preferred the previous trail of discussion which was that
content would be treated as the same class as activities -- i.e. we'd
be extending the home screen somehow, to deal with potentially lots of
activity icons, or to become additionally a hub for opening any books
that are saved on the system, or something like that. In other words,
moving the functionality of olpc-library directly onto the home
screen.

Daniel