Changes

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

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

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.

===== More relevant View(s) of Journal =====

==== 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. One of possible choices is Tag View(see proposal below). More over we could emulate "classical" Home and Journal Views.

===== Summarising =====

==== Summarising ====

Instead of having:

Instead of having:

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

==Proposal==

To achieve this target, instead of inventing new versioning scheme in sugar

To achieve this target, instead of inventing new versioning scheme in sugar

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.

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

==Pro==

With this scheme accepted user will have unified interface to all

With this scheme accepted user will have unified interface to all

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,

to produce new activity).

to produce new activity).

===Going further===

==Going further==

* Sugar integration with ASLO

* Sugar integration with ASLO