User:Alsroot/trash/Unified Objects

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 should be stored in .xo format in Journal
  • physically these .xo could stored in /usr/share but user should have access to them from the Journal
  • main purpose - we should encourage user to change all activities(including system ones)
  • 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