[IAEP] Unified Objects (was Unified bundles)

[Eben Eliason]

On Wed, Apr 8, 2009 at 1:54 PM, Wade Brainerd <wadetb at gmail.com> wrote:
> On Wed, Apr 8, 2009 at 9:12 AM, Eben Eliason <eben.eliason at gmail.com> wrote:
>> On Wed, Apr 8, 2009 at 2:20 AM, Aleksey Lim <alsroot at member.fsf.org> wrote:
>>> Proposal.
>>>
>>> To achieve this target, instead of inventing new versioning scheme in sugar
>>> (in addition to Journal), I propose treat Activities as regular Journal objects.
>>
>> I'm a little confused by this comment, as this is already the case.
>> Activities have entries in the Journal just as anything else does, and
>> are, in fact, objects in that sense. They're "special" objects since
>> they spawn fresh new objects by default, but the activity bundle is
>> still an object in itself, and should be resumable with other
>> activities which understand that object type (develop is one example;
>> a future "bundle" (zip) activity would be another).
>
> I think the Journal is capable of holding activity *bundles* as
> objects.  But the actual activity that you launch lives in
> /home/user/Activities or in /usr/share/sugar/activities and has no
> connection back to its downloaded Journal object.

This is an unfortunate side effect of the bundle format, which I see
as a technical detail and not something that should matter to the user
in any way.

> It sounds like Aleksey is proposing unpacking the activity bundles
> into the Journal, which is a really interesting idea!  It would

This actually sounds rather confusing, to me. Both the activity bundle
(zipped) and the activity (unzipped) represent the same thing: a
template for the creation of activity instances. It's just a technical
detail that we need to create the unzipped version to actually run it.
I think there needs to be one representation of each (version) of an
activity.

> certainly provide a future path for activity versioning, promote the
> creation and modification of activities to be at the same level as
> creating and modifying activity instances, allow users a way to
> transfer their created activities around, etc.

All of this, again, I see the current Journal handling just fine. If
you modify an activity bundle, you (once we support it) create a new
version of it. When you attempt to instantiate it, the bundle is
silently unpacked in the background. The zipped bundle is what you see
in the Journal, is what you click to start the activity, is what you'd
want to send to a friend, or post for download, etc. All of these
things are already facilitated by the Journal.

The big missing piece, I find, is the lack of a Bundle activity which
allows kids to peek inside and rearrange zip and other bundle formats.
The Develop activity already supports opening activity bundles from
the Journal.

Eben

> My only concern is that it might blur activities and activity
> instances for users, which could inhibit the conceptual development of
> this important computer concept.
>
> Cheers,
> Wade
>