[IAEP] Unified Objects (was Unified bundles)

[Aleksey Lim]

On Wed, Apr 08, 2009 at 01:54:45PM -0400, Wade Brainerd 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.
> 
> It sounds like Aleksey is proposing unpacking the activity bundles
> into the Journal, which is a really interesting idea!  It would
> 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.

Exactly, of course I know that we have .xo stored in Journal but they
are "dead" activities - user can use only one of them(and only non
fructose activities since 0.84 cannot upgrade activities installed in
/usr) and if user hacked activity in ~/Activities all his work will be
removed after next upgrading(there is an option to exec `cp -r` in
Terminal but is it the sugar way).

I purpose using activities from Journal like a regular jobjects - open
it(any version not only last) in some kind of devel activity(at least in
Terminal+vim:) change it, run it(w/o any tricks). And do this with many
versions of one particular activity simultaneously.

Moreover having all these versions we'll have to store many "non-dead"
activities at the same time: last "official" version to collab with most of
our fiends and bunch of custom versions to collab with friends who use
their own hacked versions(it will look like if I want to join party and
they use custom version sugar could download that version to my box
before joining).

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

-- 
Aleksey