Changes

* dbus API to get core version(at least major version)

* dbus API to get core version(at least major version)

<strong>Decoupling of Sucrose(move to pure DBus interface)</strong> [[User:Alsroot|Alsroot]] 16:14, 21 May 2009 (UTC)

<strong>Decoupling of Sucrose</strong> [[User:Alsroot|Alsroot]] 16:14, 21 May 2009 (UTC)

The major idea is to have tough core(with stable release cycle) <=> dbus API <=> unlimited count of activities that uses core functionality by dbus and do not follow 6 months release cycle(which could be overmuch for activity).

The major idea is to have tough core(with stable release cycle) <=> dbus-API/sugar-toolkit-API <=> unlimited count of activities that uses core functionality and do not follow 6 months release cycle(which could be overmuch for activity).

It could looks like:

It could looks like:

* '''core''' - glucose, six months(or so) release cycle, w/o any activities only dbus API

* '''core''' - glucose, six months(or so) release cycle, w/o any activities only API

* '''bridge''' - [[Development_Team/sugar-port|sugar-port]] for example, between all(in ideal) already deployed sugars and activities i.e. it provides backwards compatibility(so the same activity code will work on all sugars) and at the same time provides features from newest sugar(so the same activity code will use last sugar's features)

* '''bridge''' - [[Development_Team/sugar-port|sugar-port]] for example, between all(in ideal) already deployed sugars and activities i.e. it provides backwards compatibility(so the same activity code will work on all sugars) and at the same time provides features from newest sugar(so the same activity code will use last sugar's features)

* '''world''' - the rest of sugar world i.e. fructose/honey (but now there is no differences between them) that use core(by dbus) directly, if all deployed sugars have the same API for desired functionality(for example in case of preselected mime type, ObjectsChooser has different API for 0.82-0.86), or use bridge otherwise.<br>imho another point to have activities outside of core release cycle - activities have more shorter release cycle then core has

* '''world''' - the rest of sugar world i.e. fructose/honey (but now there is no differences between them) that use core directly, if all deployed sugars have the same API for desired functionality(for example in case of preselected mime type, ObjectsChooser has different API for 0.82-0.86), or use bridge otherwise.<br>imho another point to have activities outside of core release cycle - activities have more shorter release cycle then core has

And of course deployers can form any sets from these components

And of course deployers can form any sets from these components