Platform Team/Package Management System
Summary
Increase level of compartmentalization in Sucrose.
Owner
This should link to your home wiki page so we know who you are
- Name: 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
This proposal assumes that the core of sugar development(in common sense) is variety of developers rather then developers who are taking part in sugar core(glucose) development. So, it's all about seeing from activity/3rd-party developers.
From such new core POV, sugar development process will look like:
- variety of sugar activities
- that use Sugar Services
So, developers use a set of services that have theirs own API changes based schedules. Existed glucose could be treated as a big service and splited to several components but thats not a task for this proposal. Instead, it's about proposing basic infrastructure of Sugar Services and several services that are not part of glucose.
...
The major idea is instead of having 6 months to have a solid core (with stable release cycle) <=> dbus-API/sugar-toolkit-API (ideally, only dbus) <=> unlimited number of activities that use 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 - 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.
imho another point to have activities outside of core release cycle - activities have a shorter release cycle then the 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 all (in ideal) deployed 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
Release Notes
Not yet implemented