5,705
edits
Changes
User:Alsroot/trash/Unified Objects (view source)
Revision as of 01:13, 8 April 2009
, 01:13, 8 April 2009New page: ===Preamble=== (expanding of Unified_Bundles idea) Separation all objects on verbs and nouns can be failed in some cases - and moreover it will be failed when sugar will be used for ...
===Preamble===
(expanding of [[Unified_Bundles]] idea)
Separation all objects on verbs and nouns can be failed in some cases -
and moreover it will be failed when sugar will be used for purposes that
sugar was designed for - Create, Reuse, Share.
This CRS scheme works(more or less at present) for content since we have
Journal to store objects, but what about Activities?
We should encourage people CRS theirs activities as well. Only one but -
current sugar cannot work with many versions installed. At the same time
this multi versioning is cornerstone of CRS activities since we have
(should have) many versions of one particular activity installed on the
same box. And these versions could include "home made" activities not
only "official" ones. User should have possibility to treat all these
versions(of one activity) effectively to CRS them.
Home View should mutate from "storage" of activities to Tags View of
Journal objects. It could have tags cloud and etc.
===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.
Home View should mutate from "storage" of activities to Tags View of
Journal objects. It could have tags cloud and etc.
===Pro===
With this scheme accepted user will have unified interface to all
objects(and theirs versions) - content(generated by activities or
downloaded from the internet) and activities(downloaded, transfered from
friends and home made).
We could treat ASLO(Activity Library) as a Objects Library and encourage
people share theirs objects(not only activities) via
activities.sugarlabs.org(objects.sugarlabs.org? or library.sugarlabs.org?)
===Contra===
Well, it couldn't solve multi versions issue for activities out of the box,
but I'm strongly for having *only one* storage for content versions and
activities versions(since we could treat current activity as a source(noun)
to produce new activity).
(expanding of [[Unified_Bundles]] idea)
Separation all objects on verbs and nouns can be failed in some cases -
and moreover it will be failed when sugar will be used for purposes that
sugar was designed for - Create, Reuse, Share.
This CRS scheme works(more or less at present) for content since we have
Journal to store objects, but what about Activities?
We should encourage people CRS theirs activities as well. Only one but -
current sugar cannot work with many versions installed. At the same time
this multi versioning is cornerstone of CRS activities since we have
(should have) many versions of one particular activity installed on the
same box. And these versions could include "home made" activities not
only "official" ones. User should have possibility to treat all these
versions(of one activity) effectively to CRS them.
Home View should mutate from "storage" of activities to Tags View of
Journal objects. It could have tags cloud and etc.
===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.
Home View should mutate from "storage" of activities to Tags View of
Journal objects. It could have tags cloud and etc.
===Pro===
With this scheme accepted user will have unified interface to all
objects(and theirs versions) - content(generated by activities or
downloaded from the internet) and activities(downloaded, transfered from
friends and home made).
We could treat ASLO(Activity Library) as a Objects Library and encourage
people share theirs objects(not only activities) via
activities.sugarlabs.org(objects.sugarlabs.org? or library.sugarlabs.org?)
===Contra===
Well, it couldn't solve multi versions issue for activities out of the box,
but I'm strongly for having *only one* storage for content versions and
activities versions(since we could treat current activity as a source(noun)
to produce new activity).