5,705
edits
Changes
Jump to navigation
Jump to search
Line 48:
Line 48: − + + + − + + − Developers use a set of services that have their own API changes based schedules. Existed glucose packages will be treated as a big service (split to several components, but thats not a task for this proposal). This proposal is about proposing basic infrastructure of Sugar Services and several services that are not part of glucose.+ − − − − Technically, Sugar Services could be a part of glucose (or some of its releases) but from activity POV it doesn't make much sense. If an activity requires some service, [[Activity_Team/Services/Saccharin|Saccharin]] will do nothing if requested service/version is already a part of the installed glucose or install proper service(via 0install). Various activities on the same system could use various versions of the same service, in that case [[Activity_Team/Services/Saccharin|Saccharin]](via 0install) will just provide proper version to particular activity.
Platform Team/Package Management System (view source)
Revision as of 03:28, 26 December 2009
, 03:28, 26 December 2009→Detailed description
This proposal assumes that the core of Sugar development (in common sense) is a wide variety of developers, not just those developers who are taking part in Sugar core (glucose) development. It is all about seeing Sugar activity development from an activity/3rd-party developer's point of view.
This proposal assumes that the core of Sugar development (in common sense) is a wide variety of developers, not just those developers who are taking part in Sugar core (glucose) development. It is all about seeing Sugar activity development from an activity/3rd-party developer's point of view.
From such new core POV, sugar development process will look like: <!-- not sure what you are trying to say here --Walter -->
From such new core POV, sugar development process will look like:
<!-- not sure what you are trying to say here --Walter -->
<!-- * see followed "So, .." ~~~~ -->
* variety of Sugar activities
* variety of Sugar activities
* that use Sugar Services
* that use variety of Sugar Services
So, developers use a set of services that have their own API changes based schedules. Glucose could be [[Documentation Team/Services/Native packages usage|wrapped]] to regular service(s) with proper API changes based major versions e.g. if sucrose's activity API wasn't changed since 0.82(sucrose-0.x service) all activities that requires ''sucrose 0'' will be launched but instead of launching activities with requirements ''sucrose 1'', user will be warned about outdated sugar environment.
The corner stone of Sugar Services proposal is [[Activity_Team/Services/Saccharin|Saccharin]] library. This library provides installing/upgrading (via 0install) mechanism for services. The rest of services is just variety of libraries/applications/native-packages. Saccharin could be a part of glucose (some of its releases) or bundled to .xo otherwise.
The corner stone of Sugar Services proposal is [[Activity_Team/Services/Saccharin|Saccharin]] service. This service provides installing/upgrading (via 0install) mechanism for all other services. The rest of services is just variety of libraries/applications.
== FAQ ==
== FAQ ==