Platform Team/Package Management System: Difference between revisions

Line 48:

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:

From such new core POV, sugar development process will look like:

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

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.

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.

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

== FAQ ==

@@ Line 48: / Line 48: @@
 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
-* 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.
-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.
+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.
-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.
 == FAQ ==