Platform Team/Polyol: Difference between revisions

Line 13:

[[File:polyol.png|500px]]

* Glucose ~~- sugar~~ core processes.

'''Glucose''' Sugar core processes.

* Polyol - level ~~that contains glucose~~ compatibility libraries ~~and~~ libraries ~~that~~ are not tied to glucose directly ~~(or not tied at all). The reason for such a~~ level ~~is that it will be deployed by 0install, e.g., it would be possible to have a recent Polyol stack on Sugar 0.82.~~

'''Polyol''' Intermediate level libraries:

** all libraries are written in Vala, i.e., based on pure GObjects, and could be used by non-python-based activities.

* Glucose compatibility libraries (ds, shell, collab) will support several (popular among sugar deployments) glucose releases

** each Polyol component has its own release schedule, i.e., there are no Polyol official releases (it looks like in Gentoo)

* Other libraries are not tied to glucose directly

** ~~glucose compatibility components will support several~~ (~~popular among~~ sugar ~~deployers~~) ~~sugar releases~~

Key features of this level:

** except for the glucose compatibility components, all Polyol libraries are glucose independent.

* All libraries are written in Vala, i.e., based on pure GObjects, and could be used by non-python-based activities.

* Each Polyol component has its own release schedule, i.e., there are no Polyol official releases (it looks like in Gentoo).

* Activities could use these libraries on separate basis e.g. activity could use recent ''gui'' (to get access to last UI widgets) and old version of ''ds'' (because activity was coded against this particular version and new version has backward compatibility breakage in API).

* Activities (mostly not native sugar activities) could use only one library e.g. activity could use only ''ds'' library thus do not fetch additional dependencies like telepathy (via ''collab'') and gtk+ (via ''gui'').

* Activity ~~- regular~~ activities would not use glucose directly, rather they would only access glucose through the Polyol level. There is no need to code special activities, the sugar-toolkit API will be preserved, and activity developers will benefit because Polyol will support the recent sugar-toolkit API, e.g., they could use the new toolbars design even on Sugar 0.82.

'''Activity''' Regular activities would not use glucose directly, rather they would only access glucose through the Polyol level. There is no need to code special activities, the sugar-toolkit API will be preserved, and activity developers will benefit because Polyol will support the recent sugar-toolkit API, e.g., they could use the new toolbars design even on Sugar 0.82.

== Core libraries ==

@@ Line 13: / Line 13: @@
 [[File:polyol.png|500px]]
-* Glucose - sugar core processes.
+'''Glucose'''<br>Sugar core processes.
-* Polyol - level that contains glucose compatibility libraries and libraries that are not tied to glucose directly (or not tied at all).<br>The reason for such a level is that it will be deployed by 0install, e.g., it would be possible to have a recent Polyol stack on Sugar 0.82.
+'''Polyol'''<br>Intermediate level libraries:
-** all libraries are written in Vala, i.e., based on pure GObjects, and could be used by non-python-based activities.
+* Glucose compatibility libraries (ds, shell, collab) will support several (popular among sugar deployments) glucose releases
-** each Polyol component has its own release schedule, i.e., there are no Polyol official releases (it looks like in Gentoo)
+* Other libraries are not tied to glucose directly
-** glucose compatibility components will support several (popular among sugar deployers) sugar releases
+Key features of this level:
-** except for the glucose compatibility components, all Polyol libraries are glucose independent.
+* All libraries are written in Vala, i.e., based on pure GObjects, and could be used by non-python-based activities.
+* Each Polyol component has its own release schedule, i.e., there are no Polyol official releases (it looks like in Gentoo).
+* Activities could use these libraries on separate basis e.g. activity could use recent ''gui'' (to get access to last UI widgets) and old version of ''ds'' (because activity was coded against this particular version and new version has backward compatibility breakage in API).
+* Activities (mostly not native sugar activities) could use only one library e.g. activity could use only ''ds'' library thus do not fetch additional dependencies like telepathy (via ''collab'') and gtk+ (via ''gui'').
-* Activity - regular activities would not use glucose directly, rather they would only access glucose through the Polyol level.<br>There is no need to code special activities, the sugar-toolkit API will be preserved, and activity developers will benefit because Polyol will support the recent sugar-toolkit API, e.g., they could use the new toolbars design even on Sugar 0.82.
+'''Activity'''<br>Regular activities would not use glucose directly, rather they would only access glucose through the Polyol level.<br>There is no need to code special activities, the sugar-toolkit API will be preserved, and activity developers will benefit because Polyol will support the recent sugar-toolkit API, e.g., they could use the new toolbars design even on Sugar 0.82.
 == Core libraries ==