5,705
edits
Changes
Platform Team/Sugar Packaging Management System (view source)
Revision as of 13:38, 26 April 2010
, 13:38, 26 April 2010→Implementation ideas
== Implementation ideas ==
== Implementation ideas ==
There could be two level solutions that are tied to each other.
=== Intermediate level libraries ===
A decentralized development model means here that the activity developers' focus is moved from core releases to releases of core libraries they use in activities. So, the corner stone idea is switching from ''monolithic sucrose'' + ''activities'' scheme to ''monolithic sucrose'' + ''intermediate level libraries'' + ''activities''.
The major purposes in having intermediate level libraries are:
* Support several sucrose release that are popular in deployments right now, so activity developers won't have to code bunch of ifs to support several sucrose releases, they just use what current intermediate libraries can provide and activity will work (or gracefully fallback) on all sugars in the field.
* Such libraries are designed to be 0install'ed instead of installing only from native packaging systems.
=== 0install deployment mechanism ===
Services should be as independent as possible, e.g., activity developers could use the toolkit service from the 0.88 cycle with the shell service from 0.82 (since its API wasn't changed).
Intermediate level libraries will be especially useful if their recent versions could be installed on every sugar in the field in spite of the sucrose release on particular machine. 0install is obvious choice since it is (see [[Activity Team/Services|Sugar Services]] to know more about 0install support in sugar):
* Over GNU/Linux distribution mechanism
* Could be install to user's home directory i.e. without having root privileges
Other, but not less, useful 0install feature is having several versions of the code in the same time. For example if activity can work only with particular version of some intermediate library, it will work with this exact version even if it is really old, of course this library version should be still supported.
== Activity developers point of view ==
Having all mentioned above, activity developer needs only one thing to be sure that his activity will work on all sugars in the field - mention what intermediate libraries are needed and, maybe, what particular versions are. See [[Documentation_Team/Services/Activity_Developers_Guide#Using_services|Activity Developers Guide]] to know how it is implemented in 0sugar.
So, to support huge repository of doer's code (see 3rd point of [[#Purposes|purposes]]), there is no need in having huge QA to review every new piece of code, we just rely on activity coder that he mentioned all required libraries/versions (he can just type all versions he had during activity coding).