Difference between revisions of "User:Alsroot/trash/Unified Objects"
Line 53: | Line 53: | ||
** easy way to post objects to ASLO | ** easy way to post objects to ASLO | ||
− | * System activities | + | * System activities could be stored in .xo format in Journal |
− | |||
** main purpose - we should encourage user to change all activities(including system ones) | ** main purpose - we should encourage user to change all activities(including system ones) | ||
+ | ** physically these .xo could be stored in /usr/share but user should have access to them from the Journal(Tags View) | ||
** to use them user will install(from Journal) system activities to ~/Activities directory | ** to use them user will install(from Journal) system activities to ~/Activities directory | ||
− | ** basic system activities could be installed by default while first creating .sugar instance | + | ** basic system activities could be installed by default while first creating of .sugar instance |
Revision as of 01:53, 8 April 2009
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.
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).
Going further
- Sugar integration with ASLO
- common tags
- common objects(links to ASLO objects in Tags view - not only local)
- easy way to post objects to ASLO
- System activities could be stored in .xo format in Journal
- main purpose - we should encourage user to change all activities(including system ones)
- physically these .xo could be stored in /usr/share but user should have access to them from the Journal(Tags View)
- to use them user will install(from Journal) system activities to ~/Activities directory
- basic system activities could be installed by default while first creating of .sugar instance