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

[Tomeu Vizoso]

On Mon, Aug 17, 2009 at 12:02, Daniel Drake<dsd at laptop.org> wrote:
> 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.

Agreed.

> 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 understand that the current state of things is confusing, due to the
partially-implemented state of the Journal.

The idea is that the journal would have an actions view that would be
closer to what you refer to. Would contain actions that the user
carried and events that happened around the user.

Actions and events would refer to objects and there would be an object
view for browsing and searching them directly. One of the possible
implementations for object storage is just expose the $HOME dir, if we
have a fs that provides versions and metadata.

What we have today is a mix of these two.

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

It has been suggested that there's no hard difference between content
and code, because it's not easy to consistently distinguish between
them and because we want our users to author all of them. That's why
could make sense to have all them together in the same place.

Regards,

Tomeu

> Daniel
>



-- 
«Sugar Labs is anyone who participates in improving and using Sugar.
What Sugar Labs does is determined by the participants.» - David
Farning