Difference between revisions of "User:Alsroot/trash/Unified Objects"

From Sugar Labs
Jump to navigation Jump to search
 
(37 intermediate revisions by 4 users not shown)
Line 1: Line 1:
 
<noinclude>{{ GoogleTrans-en | es =show | bg =show | zh-CN =show | zh-TW =show | hr =show | cs =show | da =show | nl =show | fi =show | fr =show | de =show | el =show | hi =show | it =show | ja =show | ko =show | no =show | pl =show | pt =show | ro =show | ru =show | sv =show }}{{TOCright}}
 
<noinclude>{{ GoogleTrans-en | es =show | bg =show | zh-CN =show | zh-TW =show | hr =show | cs =show | da =show | nl =show | fi =show | fr =show | de =show | el =show | hi =show | it =show | ja =show | ko =show | no =show | pl =show | pt =show | ro =show | ru =show | sv =show }}{{TOCright}}
  
−
=== Preamble ===
+
== Preamble ==
  
 
Major ideas of this proposal.
 
Major ideas of this proposal.
Line 9: Line 9:
 
# Proposal differentiate Journal(as "storage") and Journal View(as view on "storage")
 
# Proposal differentiate Journal(as "storage") and Journal View(as view on "storage")
  
−
===== Activities as Journal Objects =====
+
==== Activities as Journal Objects ====
  
 
Separation all objects to verbs and nouns can be failed in some cases - and moreover its failed when sugar is used for purposes that it was designed for - Create, Reuse, Share.
 
Separation all objects to verbs and nouns can be failed in some cases - and moreover its failed when sugar is used for purposes that it was designed for - Create, Reuse, Share.
Line 17: Line 17:
 
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.
 
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.
  
−
===== Journal Objects is a 1st class Objects as well =====
+
==== Journal Objects is a 1st class Objects as well ====
  
 
[[Unified Bundles]] shows that Content(.xol) are the same level Objects as Activities. We could also extrapolate this idea to regular Journal Objects - it should mean user could have access to Activities, Content and Journal Objects from the same place.
 
[[Unified Bundles]] shows that Content(.xol) are the same level Objects as Activities. We could also extrapolate this idea to regular Journal Objects - it should mean user could have access to Activities, Content and Journal Objects from the same place.
  
−
===== Replace Home and Journal Views with more relevant View(s) =====
+
==== More relevant View(s) of Journal ====
  
−
Having all these Objects user should have more powerful View to threat them. One of possible choices is Tag View(see proposal below). More over we could emulate "classical" Home and Journal Views.
+
Having all these Objects user should have more powerful View to threat them. See [http://wiki.laptop.org/go/Journal%2C_reloaded Journal reloaded] and [[Design_Team/Designs/Journal#01|Journal mockups]] for proposals. Moreover  we could emulate "classical" Home and Journal Views.
  
−
===== Summarising =====
+
==== Summarising ====
  
 
Instead of having:
 
Instead of having:
−
* Activity bundles(.xo in Journal or in /usr)
+
* Activity bundles(.xo in Journal)
 
* Content bundles(.xol in Journal)
 
* Content bundles(.xol in Journal)
−
* Activities(from Home View)
+
* Activities(from Home View and placed to /usr or ~/Activities)
 
* Content(in meaning of [[Unified Bundles]])
 
* Content(in meaning of [[Unified Bundles]])
 
* Journal Objects(from old Journal View)
 
* Journal Objects(from old Journal View)
Line 36: Line 36:
 
We could have only Objects in Journal(in terms of "storage" not Journal View). And operate these Objects in one unified way - Create(or copy existed) in Journal, Reuse(Change) them in Journal and Share Journal Objects.
 
We could have only Objects in Journal(in terms of "storage" not Journal View). And operate these Objects in one unified way - Create(or copy existed) in Journal, Reuse(Change) them in Journal and Share Journal Objects.
  
−
===Proposal===
+
== Implementation ==
  
−
To achieve this target, instead of inventing new versioning scheme in sugar
+
* [[Features/Object Bundles]]
−
(in addition to Journal), I propose treat Activities as regular Journal objects.
+
* [[Features/Activity Objects]]
 +
* [[Features/Unified Browser for Objects]]
 +
* [[Features/Object Collections]]
 +
* [[Features/Peer to Peer Objects Sharing]]
 +
* [[Activities/Library]]
  
−
Home View should mutate from "storage" of activities to Tags View of
+
==Pro==
−
Journal objects. It could have tags cloud and etc.
 
−
 
 
−
And final, all sugar stuff could be treated as Objects in Journal(Journal as a technical term not Journal View). User could operate them from various View backends: Tags View, "classical" Home and Journal Views.
 
−
 
 
−
===Pro===
 
  
 
With this scheme accepted user will have unified interface to all
 
With this scheme accepted user will have unified interface to all
Line 57: Line 56:
 
activities.sugarlabs.org(objects.sugarlabs.org? or library.sugarlabs.org?)
 
activities.sugarlabs.org(objects.sugarlabs.org? or library.sugarlabs.org?)
  
−
===Contra===
+
==Contra==
  
 
Well, it couldn't solve multi versions issue for activities out of the box,
 
Well, it couldn't solve multi versions issue for activities out of the box,
Line 64: Line 63:
 
to produce new activity).
 
to produce new activity).
  
−
===Going further===
+
==Going further==
 +
 
 +
==== Sugar integration with http://activities.sugarlabs.org/ ====
 +
* upload to ASLO all kinds of Objects not only Activities
 +
* common Tags
 +
* common Objects(links to ASLO objects in Tags View)
 +
* easy way to post objects to ASLO
 +
* Objects updater which uses Activity Library as a source of updates
 +
 
 +
==== System activities could be stored in Journal as well ====
 +
* 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)
 +
* basic system activities could be installed by default while first creating of .sugar instance
  
−
* Sugar integration with ASLO
+
==== Sugar Infection ====
−
** common tags
+
Auto migration of activities before joining to session which uses another version of activity
−
** 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 Journal as well
+
==== Sets of Objects ====
−
** main purpose - we should encourage user to change all activities(including system ones)
+
To support [http://dev.sugarlabs.org/ticket/540 meta bundles]
−
** physically these .xo could be stored in /usr/share but user should have access to them from the Journal(Tags View)
 
−
** basic system activities could be installed by default while first creating of .sugar instance
 

Latest revision as of 13:27, 1 March 2010

Preamble

Major ideas of this proposal.

NOTE

  1. This sections talks not about bundles(activity or content) but about Activities and Content themselves.
  2. Proposal differentiate Journal(as "storage") and Journal View(as view on "storage")

Activities as Journal Objects

Separation all objects to verbs and nouns can be failed in some cases - and moreover its failed when sugar is used for purposes that it 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.

Journal Objects is a 1st class Objects as well

Unified Bundles shows that Content(.xol) are the same level Objects as Activities. We could also extrapolate this idea to regular Journal Objects - it should mean user could have access to Activities, Content and Journal Objects from the same place.

More relevant View(s) of Journal

Having all these Objects user should have more powerful View to threat them. See Journal reloaded and Journal mockups for proposals. Moreover we could emulate "classical" Home and Journal Views.

Summarising

Instead of having:

  • Activity bundles(.xo in Journal)
  • Content bundles(.xol in Journal)
  • Activities(from Home View and placed to /usr or ~/Activities)
  • Content(in meaning of Unified Bundles)
  • Journal Objects(from old Journal View)

We could have only Objects in Journal(in terms of "storage" not Journal View). And operate these Objects in one unified way - Create(or copy existed) in Journal, Reuse(Change) them in Journal and Share Journal Objects.

Implementation

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 http://activities.sugarlabs.org/

  • upload to ASLO all kinds of Objects not only Activities
  • common Tags
  • common Objects(links to ASLO objects in Tags View)
  • easy way to post objects to ASLO
  • Objects updater which uses Activity Library as a source of updates

System activities could be stored in Journal as well

  • 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)
  • basic system activities could be installed by default while first creating of .sugar instance

Sugar Infection

Auto migration of activities before joining to session which uses another version of activity

Sets of Objects

To support meta bundles

Retrieved from "https://wiki.sugarlabs.org/index.php?title=User:Alsroot/trash/Unified_Objects&oldid=49218"