Changes

Line 32: Line 32:  
=== All sugar developers ===
 
=== All sugar developers ===
   −
Services are intended to decentralize sugar development process e.g. if you have some idea in mind, you can start pushing it through entirely release queue to get it in the next(maybe not nearest) Sucrose release. The core issue here is that there are only YES and NO answers to inclusion your feature to Sucrose, so if there is 51% against and 49% for inclusion, feature could be rejected/postponed. Services make development process more flexible and let developer benefit 49% of users.
+
Services are intended to decentralize Sugar development process. If you have some idea in mind, you can start pushing it through the Sucrose release queue to get it in the next (maybe not nearest) release. However, since the release process is binary—either your feature is included or not—Services offers more flexibility. For example:
 +
* some features are of arguable general benefit; Sugar Services would allow interested end users to efficiently test (and even deploy) such features;
 +
* some feature are only stable in limited environments; Sugar Services would allow deployment in limited environmets without the risk of destabilizing the rest of Sugar.
   −
Any developer can get benefits from 0install [http://0install.net/goals.html features] to:
+
A developer benefits from 0install [http://0install.net/goals.html features] by:
   −
* let users of all(if service is not tied to particular sugar) deployed sugars, benefit from your feature instead of having it only in last Sucrose release;<br>for example [[Documentation_Team/Services/Activity_Triggers|Activity Triggers]] services
+
* letting users of all deployed Sucrose releases benefit from your new feature instead of having it only in a specific (latest) Sucrose release; for example [[Documentation_Team/Services/Activity_Triggers|Activity Triggers]] services;
* provide libraries or applications that are not intended to be included to [[0.86/Platform_Components|Sugar Platform]]
  −
** could be used by few activities
  −
** have shorter or longer release/support schedules
  −
* deploy dependencies that are specific to particular activity e.g. some python activities have C libraries, using Services, activity developer should not bundle all binaries that sugar supports but provide links to binaries that he managed to build and let Services build C libraries from sources on user side in the rest of cases
      
See [[Activity Team/Documentation/Services/Service Developers Guide|Service Developers Guide]] to know how to create service.
 
See [[Activity Team/Documentation/Services/Service Developers Guide|Service Developers Guide]] to know how to create service.