5,705
edits
Changes
Jump to navigation
Jump to search
Platform Team/Package Management System (view source)
Revision as of 11:54, 12 July 2009
, 11:54, 12 July 2009Created page with '<noinclude>{{GoogleTrans-en}}{{TOCright}}</noinclude> <!-- All fields on this form are required to be accepted. We also request that you maintain the same order of sections so …'
<noinclude>{{GoogleTrans-en}}{{TOCright}}</noinclude>
<!-- All fields on this form are required to be accepted.
We also request that you maintain the same order of sections so that all of the feature pages are uniform. -->
<!-- The actual name of your feature page should look something like: Features/Your Feature Name. This keeps all features in the same namespace -->
== Summary ==
Increase level of compartmentalization in Sucrose.
== Owner ==
''This should link to your home wiki page so we know who you are''
* Name: [[User:AcountName| Your Name]]
''Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved''
* Email: <your email address so we can contact you, invite you to meetings, etc.>
== Current status ==
* Targeted release: ASAP
* Last updated: Sun Jul 12 15:48:08 UTC 2009
* Percentage of completion: 0%
== Detailed Description ==
The major idea is to have tough core(with stable release cycle) <=> dbus-API/sugar-toolkit-API(in ideal only dbus) <=> unlimited count of activities that uses core functionality and do not follow 6 months release cycle(which could be overmuch for activity).
It could looks like:
* '''core''' - glucose, six months(or so) release cycle, w/o any activities, only API
** in ideal, it should have only dbus API
* '''bridge''' - [[Development_Team/sugar-port|sugar-port]] for example, between all(in ideal) already deployed sugars and activities i.e. it provides backwards compatibility(so the same activity code will work on all sugars) and at the same time provides features from newest sugar(so the same activity code will use last sugar's features)
** we could write this level in vala to provide core functionality for wide range of programming languages
* '''world''' - the rest of sugar world i.e. fructose/honey (but now there are no differences between them) that use core directly, if all deployed sugars have the same API for desired functionality(for example in case of preselected mime type, ObjectsChooser has different API for 0.82-0.86), or use bridge otherwise.<br>imho another point to have activities outside of core release cycle - activities have more shorter release cycle then core has
And of course deployers can form any sets from these components
Core Bridge World
+------------+ +------------+
| Sugar-0.82 |---+ +---| Activity A |
+------------+ | +---------------------------+ | +------------+
+------------+ | | sugar-port | | +------------+
| ... |--dbus--| do not fail on 0.82 |---+---| ... |
+------------+ | | but uses all 777 features | | +------------+
+------------+ | +---------------------------+ | +------------+
| Sugar-777 |---+ +---| Activity Z |
+------------+ +------------+
== Benefit to Sugar ==
Make sugar environment more straightforward by decoupling core from other stuff and using tough and well maintainable dbus API to let activities run on deployed(in ideal) sugar platforms.
== Scope ==
Sugar core parts.
== How To Test ==
''Not yet implemented''
== User Experience ==
''Not yet implemented''
== Dependencies ==
''Not yet implemented''
== Contingency Plan ==
None necessary, revert to previous release behaviour.
== Documentation ==
* [http://www.mail-archive.com/sugar@lists.laptop.org/msg04623.html Michael Stone's email]
== Release Notes ==
''Not yet implemented''
== Comments and Discussion ==
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] <!-- This adds a link to the "discussion" tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page -->
[[Category:FeaturePageIncomplete]]
[[Category:Feature]]
<!-- All fields on this form are required to be accepted.
We also request that you maintain the same order of sections so that all of the feature pages are uniform. -->
<!-- The actual name of your feature page should look something like: Features/Your Feature Name. This keeps all features in the same namespace -->
== Summary ==
Increase level of compartmentalization in Sucrose.
== Owner ==
''This should link to your home wiki page so we know who you are''
* Name: [[User:AcountName| Your Name]]
''Include you email address that you can be reached should people want to contact you about helping with your feature, status is requested, or technical issues need to be resolved''
* Email: <your email address so we can contact you, invite you to meetings, etc.>
== Current status ==
* Targeted release: ASAP
* Last updated: Sun Jul 12 15:48:08 UTC 2009
* Percentage of completion: 0%
== Detailed Description ==
The major idea is to have tough core(with stable release cycle) <=> dbus-API/sugar-toolkit-API(in ideal only dbus) <=> unlimited count of activities that uses core functionality and do not follow 6 months release cycle(which could be overmuch for activity).
It could looks like:
* '''core''' - glucose, six months(or so) release cycle, w/o any activities, only API
** in ideal, it should have only dbus API
* '''bridge''' - [[Development_Team/sugar-port|sugar-port]] for example, between all(in ideal) already deployed sugars and activities i.e. it provides backwards compatibility(so the same activity code will work on all sugars) and at the same time provides features from newest sugar(so the same activity code will use last sugar's features)
** we could write this level in vala to provide core functionality for wide range of programming languages
* '''world''' - the rest of sugar world i.e. fructose/honey (but now there are no differences between them) that use core directly, if all deployed sugars have the same API for desired functionality(for example in case of preselected mime type, ObjectsChooser has different API for 0.82-0.86), or use bridge otherwise.<br>imho another point to have activities outside of core release cycle - activities have more shorter release cycle then core has
And of course deployers can form any sets from these components
Core Bridge World
+------------+ +------------+
| Sugar-0.82 |---+ +---| Activity A |
+------------+ | +---------------------------+ | +------------+
+------------+ | | sugar-port | | +------------+
| ... |--dbus--| do not fail on 0.82 |---+---| ... |
+------------+ | | but uses all 777 features | | +------------+
+------------+ | +---------------------------+ | +------------+
| Sugar-777 |---+ +---| Activity Z |
+------------+ +------------+
== Benefit to Sugar ==
Make sugar environment more straightforward by decoupling core from other stuff and using tough and well maintainable dbus API to let activities run on deployed(in ideal) sugar platforms.
== Scope ==
Sugar core parts.
== How To Test ==
''Not yet implemented''
== User Experience ==
''Not yet implemented''
== Dependencies ==
''Not yet implemented''
== Contingency Plan ==
None necessary, revert to previous release behaviour.
== Documentation ==
* [http://www.mail-archive.com/sugar@lists.laptop.org/msg04623.html Michael Stone's email]
== Release Notes ==
''Not yet implemented''
== Comments and Discussion ==
* See [[{{TALKPAGENAME}}|discussion tab for this feature]] <!-- This adds a link to the "discussion" tab associated with your page. This provides the ability to have ongoing comments or conversation without bogging down the main feature page -->
[[Category:FeaturePageIncomplete]]
[[Category:Feature]]