Features/Automatic activity updates - Revision history

Godiard at 15:26, 18 July 2014

2014-07-18T15:26:42Z

← Older revision		Revision as of 11:26, 18 July 2014
Line 1:		Line 1:
	<noinclude>		<noinclude>
	[[Category:Feature Page Incomplete]]		[[Category:Feature Page Incomplete]]
	[[Category:~~Feature~~\|Automatic activity updates]]		[[Category:FeatureLanded\|Automatic activity updates]]
	</noinclude>		</noinclude>

DanielDrake: /* Scope and implementation */

2013-06-21T18:58:28Z

Scope and implementation

← Older revision		Revision as of 14:58, 21 June 2013
Line 61:		Line 61:
	When an update successfully completes, the update time is recorded in the gconf key <tt>/desktop/sugar/update/last_activity_update</tt>. The amount of time that passes before an automatic activity update is executed is defined by the gconf key <tt>/desktop/sugar/update/auto_update_frequency</tt>, units in days, default 0 (which means no periodic update).		When an update successfully completes, the update time is recorded in the gconf key <tt>/desktop/sugar/update/last_activity_update</tt>. The amount of time that passes before an automatic activity update is executed is defined by the gconf key <tt>/desktop/sugar/update/auto_update_frequency</tt>, units in days, default 0 (which means no periodic update).

	The gconf key <tt>/desktop/sugar/update/~~activity_update_mechanism~~</tt> will specify which update mechanism to use (ASLO or microformat), and the <tt>/desktop/sugar/update/~~activity_update_uri~~</tt> gconf key will specify the base server URI to use.		The gconf key <tt>/desktop/sugar/update/backend</tt> will specify which update mechanism to use (ASLO or microformat), and the <tt>/desktop/sugar/update/microformat_update_url</tt> gconf key will specify the base server URI to use for the microformat update backend.

			The idea is that the deployer sets the appropriate gconf keys according to his preferences and infrastructure.

	The core of the activity update code (src/extensions/cpsection/update/model.py and the backends) will be moved into src/jarabe/model/update, where it will be shared between the activity update control panel, and the automatic background update.		The core of the activity update code (src/extensions/cpsection/update/model.py and the backends) will be moved into src/jarabe/model/update, where it will be shared between the activity update control panel, and the automatic background update.

DanielDrake: /* Scope and implementation */

2013-06-13T22:01:08Z

Scope and implementation

← Older revision		Revision as of 18:01, 13 June 2013
Line 58:		Line 58:
	To handle periodic updates (when system upgrades have not happened), 10 minutes after launch, Sugar will check if sufficient time has passed since the last successful update. If a configured threshold has been met, an activity update will be run. This check will then be repeated at 60 minute intervals.		To handle periodic updates (when system upgrades have not happened), 10 minutes after launch, Sugar will check if sufficient time has passed since the last successful update. If a configured threshold has been met, an activity update will be run. This check will then be repeated at 60 minute intervals.

	The activity-update-urgent flag is set based on the presence of the file <tt>~/.sugar~~/default/activity_update_urgent~~</tt>.		The activity-update-urgent flag is set based on the presence of the file <tt>~/.sugar-update</tt>.
	When an update successfully completes, the update time is recorded in the gconf key <tt>/desktop/sugar/update/last_activity_update</tt>. The amount of time that passes before an automatic activity update is executed is defined by the gconf key <tt>/desktop/sugar/update/auto_update_frequency</tt>, units in days, default 0 (which means no periodic update).		When an update successfully completes, the update time is recorded in the gconf key <tt>/desktop/sugar/update/last_activity_update</tt>. The amount of time that passes before an automatic activity update is executed is defined by the gconf key <tt>/desktop/sugar/update/auto_update_frequency</tt>, units in days, default 0 (which means no periodic update).

DanielDrake: /* Scope and implementation */

2013-06-11T22:31:32Z

Scope and implementation

← Older revision		Revision as of 18:31, 11 June 2013
Line 71:		Line 71:
	When the user opens the "Software Update" section of the control panel, the control panel code will attempt to start listening to any ongoing update session. This means that if the user opens the control panel while an automatic update is happening in the background, that update effectively gets moved to the foreground, and the user can keep an eye on what is happening. If the control panel is opened while no update is active, the user will be able to launch a manually-invoked update in the way that the existing activity updater operates.		When the user opens the "Software Update" section of the control panel, the control panel code will attempt to start listening to any ongoing update session. This means that if the user opens the control panel while an automatic update is happening in the background, that update effectively gets moved to the foreground, and the user can keep an eye on what is happening. If the control panel is opened while no update is active, the user will be able to launch a manually-invoked update in the way that the existing activity updater operates.

	#3707 ~~will be addressed as part of this implementation~~.		The implementation will also bring in some cleanups to Bundle handling including a fix to #3707.

	== How To Test ==		== How To Test ==

DanielDrake at 22:30, 11 June 2013

2013-06-11T22:30:30Z

← Older revision		Revision as of 18:30, 11 June 2013
Line 18:		Line 18:
	== Detailed Description ==		== Detailed Description ==

	''This proposal is based around the needs of the OLPC project in Nicaragua, but reflects a common need (current or future) of other OLPC implementations ~~that I have visited~~.''		''This proposal is based around the needs of the OLPC project in Nicaragua, but reflects a common need (current or future) of other OLPC implementations as well.''

	'''The problem:''' Software updates. Previously, the local foundation visited every school at the end of the academic year and reflashed all the laptops, to provide them with a software update. Now the program has expanded to over 20,000 laptops, that is no longer practical nor affordable.		'''The problem:''' Software updates. Previously, the local foundation visited every school at the end of the academic year and reflashed all the laptops, to provide them with a software update. Now the program has expanded to over 20,000 laptops, that is no longer practical nor affordable.
Line 29:		Line 29:
	* Relying on 20,000 children to all perform this step (only when connectivity is available), which is not even something that occurs very naturally for them, is not something that would bring good results.		* Relying on 20,000 children to all perform this step (only when connectivity is available), which is not even something that occurs very naturally for them, is not something that would bring good results.
	* If the activity update process fails (e.g. no connectivity), the message doesn't come back again. But activity updating is something absolutely necessary at this point, so it should not give up so easily.		* If the activity update process fails (e.g. no connectivity), the message doesn't come back again. But activity updating is something absolutely necessary at this point, so it should not give up so easily.
	* It's something that should be automatic.		* It's something that simply should be automatic.

	The proposed solution is to remove this message and adds an automatic software update feature that runs in the background. This would be off by default, but could be enabled by deployers of Sugar via system configuration.		The proposed solution is to remove this message and adds an automatic software update feature that runs in the background. This would be off by default, but could be enabled by deployers of Sugar via system configuration.
Line 48:		Line 48:
	Other functionalities also become available. For example, currently there is no hands-off way for a Sugar deployer to push a new activity to the existing install-base. But, as this activity update would run automatically once per week, this now becomes easy.		Other functionalities also become available. For example, currently there is no hands-off way for a Sugar deployer to push a new activity to the existing install-base. But, as this activity update would run automatically once per week, this now becomes easy.

	Sugar will gain support for the OLPC activity update microformat which is used in the field.		Sugar will gain support for the [[Activity_Team/Activity_Microformat\|OLPC activity update microformat]] which is widely used in the field.

	The "you should update your activities" message, which has been seen as a source of user confusion, will go away.		The "you should update your activities" message, which has been seen as a source of user confusion, will go away.

	== Scope ==		== Scope and implementation ==

	Upon establishing a network connection, or upon starting with a network connection already established, where the activity updater has been enabled in the configuration, Sugar will examine whether it needs to launch an automatic activity update if the activity-update-urgent flag is set, or if the last update ~~happened beyond~~ a ~~configurable amount of time in the past~~.		Upon establishing a network connection, or upon starting with a network connection already established, where the activity updater has been enabled in the configuration, Sugar will examine whether it needs to launch an automatic activity update if the activity-update-urgent flag is set.

			To handle periodic updates (when system upgrades have not happened), 10 minutes after launch, Sugar will check if sufficient time has passed since the last successful update. If a configured threshold has been met, an activity update will be run. This check will then be repeated at 60 minute intervals.

	The activity-update-urgent flag is set based on the presence of the file <tt>~/.sugar/default/activity_update_urgent</tt>.		The activity-update-urgent flag is set based on the presence of the file <tt>~/.sugar/default/activity_update_urgent</tt>.
Line 61:		Line 63:
	The gconf key <tt>/desktop/sugar/update/activity_update_mechanism</tt> will specify which update mechanism to use (ASLO or microformat), and the <tt>/desktop/sugar/update/activity_update_uri</tt> gconf key will specify the base server URI to use.		The gconf key <tt>/desktop/sugar/update/activity_update_mechanism</tt> will specify which update mechanism to use (ASLO or microformat), and the <tt>/desktop/sugar/update/activity_update_uri</tt> gconf key will specify the base server URI to use.

	The core of the activity ~~updating~~ code (~~looking for updates, downloading them, installing them~~) will be moved ~~to a dbus-activated service on~~ the ~~session bus with name XXX. This service, referred to as~~ activity~~-updater~~, ~~will automatically exit after 2 minutes of inactivity when no activity updates are ongoing. It will only allow one activity~~ update ~~to happen at a time~~. ~~The D-Bus API will have the following methods and signals:~~		The core of the activity update code (src/extensions/cpsection/update/model.py and the backends) will be moved into src/jarabe/model/update, where it will be shared between the activity update control panel, and the automatic background update.

	* GetStatus(): get the status of the current activity update ~~session (if any). Returns the status code last emitted from the SessionStatus signal,~~ the ~~number of activities that are included in any in~~-~~progress update, and the number of activity updates already completed~~.		The background update will be run in the main sugar-shell process. A previous design considered making this a separate service, but upon investigation, the in-process bundle registry is a key part of the whole process, and keeping things in process reduces scope/complexity of this feature substantially.
	* GetCurrentUpdateStatus(): get information about the current activity being updated: its name, download size, a ~~boolean flag indicating whether the download has completed~~, ~~and a percentage progress indication (of either the download or the installation).~~
	* Cancel(): Cancel the ongoing update session, ~~waiting for a safe point before cancelling (e.g. to avoid aborting halfway through installing an activity). This will return immediately but~~ the ~~cancel will not be complete until indicated by the SessionStatus signal.~~
	* FindUpdates(array of activities to check, optional automatic update parameter): Start a new update session, querying for available activity updates. Returns a ~~list~~ of updates available. Each list entry will have: (bundle_id, URL, download_size, current_installed_version_number, update_version_number). An optional parameter can be passed to trigger automatic upgrade to the ~~new activities that are found.~~
	* GetDetails(bundle_id): For a given bundle_id already identified as an update, ~~download and return the activity name (localised)~~ and ~~icon.~~
	* DoUpdate(bundle_id_1, bundle_id_2, ...): For the given bundle_ids already identified as updates and passed in ~~as parameters, perform the activity update~~ process ~~(download, install)~~.

	* Signal ActivityUpdating(bundle_id, download_size, download_completed, progress): Raised when an activity ~~update~~ is ~~started, and then every 10 seconds until it is completed. The download_completed flag indicates whether the activity~~ is ~~downloading or installing, and~~ the ~~progress parameter indicates the percentage of the download or install.~~		The one significant change needed is that bundleregistry must offer asynchronous activity installation to avoid horrible UI hangs while background updates are going on. This will be done by bundleregistry doing its install/upgrade work in a separate thread. GIL contention is not a concern because pygobject is good at dropping the GIL (i.e. it's never held on idle) and the installation thread is IO-bound so is not expected to contend the GIL much either. Beyond threading, the only other added complexity is that the bundle registry must now be protected by a lock, as the installation thread needs to use it very briefly before starting any update.
	* Signal ActivityUpdated(~~bundle_id, success): Raised when an activity update completes, with the success flag indicating success or failure~~.
	* Signal UpdateCompleted(success): Raised when an update session completes, with a flag indicating whether errors were encountered or not.
	* Signal SessionStatus(status)~~: Raised with a code indicating~~ the ~~status of~~ the ~~activity updater~~.
	** 0: inactive
	** 1: new session opened, ~~for automatic activity update~~
	** 2: new session opened, ~~updates have been queried~~
	** 3: activity download/installation ~~is in progress~~

	~~This API is intended for internal~~ use ~~only.~~

	~~When Sugar wants to launch an automatic activity~~ update~~, it will make a dbus method call to FindUpdates(), requesting that an automatic upgrade is performed~~.

	When the user opens the "Software Update" section of the control panel, the control panel code will attempt to start listening to any ongoing update session. This means that if the user opens the control panel while an automatic update is happening in the background, that update effectively gets moved to the foreground, and the user can keep an eye on what is happening. If the control panel is opened while no update is active, the user will be able to launch a manually-invoked update in the way that the existing activity updater operates.		When the user opens the "Software Update" section of the control panel, the control panel code will attempt to start listening to any ongoing update session. This means that if the user opens the control panel while an automatic update is happening in the background, that update effectively gets moved to the foreground, and the user can keep an eye on what is happening. If the control panel is opened while no update is active, the user will be able to launch a manually-invoked update in the way that the existing activity updater operates.

	~~Activity installation/update will be done with the sugar-toolkit bundle API (like sugar-install-bundle). Sugar~~ will ~~become aware of these events through the way it already watches the filesystem. It might~~ be ~~worth addressing #3707~~ as part of this implementation ~~effort so that this is fully reliable.~~		#3707 will be addressed as part of this implementation.

	~~== Future possibilities ==~~

	* Improve the bundle registry so that it is accessible over dbus and doesn't need the update service to also create its own registry in memory.

	~~==UI Design==~~
	~~''Does the feature have a direct impact on the work flow, or does it need a UI? Link here mockups, or add detailed descriptions~~.''

	== How To Test ==		== How To Test ==
	{{:{{PAGENAME}}/Testing}}		{{:{{PAGENAME}}/Testing}}

	== User Experience ==		== User Experience ==
	''If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice.''		''If this feature is noticeable by its target audience, how will their experiences change as a result? Describe what they will see or notice.''

	~~== Dependencies ==~~
	''What other packages (RPMs) depend on this package? Are there changes outside the developers' control on which completion of this feature depends? In other words, does your feature depend on completion of another feature owned by someone else or that you would need to coordinate, which might cause you to be unable to finish on time? Other upstream projects like Python?''

	~~== Contingency Plan ==~~
	''If you cannot complete your feature by the final development freeze, what is the backup plan? This might be as simple as "None necessary, revert to previous release behaviour." Or it might not. If your feature is not completed in time, we want to assure others that other parts of Sugar will not be in jeopardy.''

	~~== Documentation ==~~
	''Is there upstream documentation on this feature, or notes you have written yourself? Has this topic been discussed in the mailing list or during a meeting? Link to that material here so other interested developers can get involved.''

	== Release Notes ==		== Release Notes ==

DanielDrake at 21:39, 3 June 2013

2013-06-03T21:39:09Z

FGrose: sort in category list

2012-08-21T12:54:41Z

sort in category list

← Older revision		Revision as of 08:54, 21 August 2012
Line 1:		Line 1:
	<noinclude>		<noinclude>
	[[Category:Feature Page Incomplete]]		[[Category:Feature Page Incomplete]]
	[[Category:Feature\|.]]		[[Category:Feature\|Automatic activity updates]]
	</noinclude>		</noinclude>

DanielDrake: /* Scope */

2012-08-09T21:03:39Z

Scope

← Older revision		Revision as of 17:03, 9 August 2012
Line 56:		Line 56:
	Upon establishing a network connection, or upon starting with a network connection already established, where the activity updater has been enabled in the configuration, Sugar will examine whether it needs to launch an automatic activity update if the activity-update-urgent flag is set, or if the last update happened beyond a configurable amount of time in the past.		Upon establishing a network connection, or upon starting with a network connection already established, where the activity updater has been enabled in the configuration, Sugar will examine whether it needs to launch an automatic activity update if the activity-update-urgent flag is set, or if the last update happened beyond a configurable amount of time in the past.

	The activity-update-urgent flag is set based on the presence of the file ~~XXX~~.		The activity-update-urgent flag is set based on the presence of the file <tt>~/.sugar/default/activity_update_urgent</tt>.
	When an update successfully completes, the update time is recorded in the gconf key ~~XXX~~. The amount of time that passes before an automatic activity update is executed is defined by the gconf key ~~XXX~~, units in days, default ~~7, zero~~ means no periodic update.		When an update successfully completes, the update time is recorded in the gconf key <tt>/desktop/sugar/update/last_activity_update</tt>. The amount of time that passes before an automatic activity update is executed is defined by the gconf key <tt>/desktop/sugar/update/auto_update_frequency</tt>, units in days, default 0 (which means no periodic update).

	The ~~activity updater will be enabled in the boolean~~ gconf key ~~XXX (disabled by default). The gconf key XXX~~ will specify which update mechanism to use (ASLO or microformat), and the ~~XXX~~ gconf key will specify the base server URI to use.		The gconf key <tt>/desktop/sugar/update/activity_update_mechanism</tt> will specify which update mechanism to use (ASLO or microformat), and the <tt>/desktop/sugar/update/activity_update_uri</tt> gconf key will specify the base server URI to use.

	The core of the activity updating code (looking for updates, downloading them, installing them) will be moved to a dbus-activated service on the session bus with name XXX. This service, referred to as activity-updater, will automatically exit after 2 minutes of inactivity when no activity updates are ongoing. It will only allow one activity update to happen at a time. The D-Bus API will have the following methods and signals:		The core of the activity updating code (looking for updates, downloading them, installing them) will be moved to a dbus-activated service on the session bus with name XXX. This service, referred to as activity-updater, will automatically exit after 2 minutes of inactivity when no activity updates are ongoing. It will only allow one activity update to happen at a time. The D-Bus API will have the following methods and signals:
Line 69:		Line 69:
	* GetDetails(bundle_id): For a given bundle_id already identified as an update, download and return the activity name (localised) and icon.		* GetDetails(bundle_id): For a given bundle_id already identified as an update, download and return the activity name (localised) and icon.
	* DoUpdate(bundle_id_1, bundle_id_2, ...): For the given bundle_ids already identified as updates, perform the activity update process (download, install).		* DoUpdate(bundle_id_1, bundle_id_2, ...): For the given bundle_ids already identified as updates, perform the activity update process (download, install).
	* StartAutomaticUpdate(): internally perform QueryUpdates() and then run DoUpdates() on all available updates. Returns immediately.		* StartAutomaticUpdate(): internally perform QueryUpdates() and then run DoUpdates() on all available updates. Returns immediately having kicked off the process internally.

	* Signal ActivityUpdating(bundle_id, download_size, download_completed, progress): Raised when an activity update is started, and then every 10 seconds until it is completed. The download_completed flag indicates whether the activity is downloading or installing, and the progress parameter indicates the percentage of the download or install.		* Signal ActivityUpdating(bundle_id, download_size, download_completed, progress): Raised when an activity update is started, and then every 10 seconds until it is completed. The download_completed flag indicates whether the activity is downloading or installing, and the progress parameter indicates the percentage of the download or install.
Line 86:		Line 86:
	When the user opens the "Software Update" section of the control panel, the control panel code will attempt to start listening to any ongoing update session. This means that if the user opens the control panel while an automatic update is happening in the background, that update effectively gets moved to the foreground, and the user can keep an eye on what is happening. If the control panel is opened while no update is active, the user will be able to launch a manually-invoked update in the way that the existing activity updater operates.		When the user opens the "Software Update" section of the control panel, the control panel code will attempt to start listening to any ongoing update session. This means that if the user opens the control panel while an automatic update is happening in the background, that update effectively gets moved to the foreground, and the user can keep an eye on what is happening. If the control panel is opened while no update is active, the user will be able to launch a manually-invoked update in the way that the existing activity updater operates.

	To update ~~an individual activity,~~ the activity updater will ~~perform the following steps~~ in ~~this order:~~		Activity installation/update will be done with the Sugar bundle registry API (jarabe.model.bundleregistry). The activity updater will instantiate its own bundle registry object in its own process.
	~~# Download new activity bundle to temporary storage~~
	~~# Delete existing activity~~
	~~# Install new activity version~~

	~~This is intended as a compromise between not requiring the amount of disk space needed for two unzipped versions~~ of the ~~activity, and not deleting~~ the ~~existing activity~~ so ~~early~~ that ~~the user~~ is ~~potentially left without the activity for a long time (especially if the download then fails)~~.		Sugar will become aware of these events through the way it already watches the filesystem. Ticket #3707 will be fixed as part of this implementation effort so that this is fully reliable.

	Activity installation/deinstallation will be done with the Sugar bundle registry API (jarabe.model.bundleregistry). The activity updater will instantiate its own bundle registry object in its own process.		== Future possibilities ==

	~~Sugar will become aware of these events through~~ the ~~way it already watches the filesystem. Ticket #3707 will be fixed as part of this implementation effort~~ so that ~~this~~ is ~~fully reliable~~.		* Improve the bundle registry so that it is accessible over dbus and doesn't need the update service to also create its own registry in memory.

	==UI Design==		==UI Design==

DanielDrake at 20:45, 9 August 2012

2012-08-09T20:45:06Z

Show changes

DanielDrake: Created page with " Category:Feature Page Incomplete .

← Older revision		Revision as of 17:39, 3 June 2013
Line 66:		Line 66:
	* GetCurrentUpdateStatus(): get information about the current activity being updated: its name, download size, a boolean flag indicating whether the download has completed, and a percentage progress indication (of either the download or the installation).		* GetCurrentUpdateStatus(): get information about the current activity being updated: its name, download size, a boolean flag indicating whether the download has completed, and a percentage progress indication (of either the download or the installation).
	* Cancel(): Cancel the ongoing update session, waiting for a safe point before cancelling (e.g. to avoid aborting halfway through installing an activity). This will return immediately but the cancel will not be complete until indicated by the SessionStatus signal.		* Cancel(): Cancel the ongoing update session, waiting for a safe point before cancelling (e.g. to avoid aborting halfway through installing an activity). This will return immediately but the cancel will not be complete until indicated by the SessionStatus signal.
	* ~~QueryUpdates~~(): Start a new update session, querying for available activity updates. Returns a list of ~~activities~~ available. Each list entry will have: (bundle_id, URL, download_size, current_installed_version_number, update_version_number).		* FindUpdates(array of activities to check, optional automatic update parameter): Start a new update session, querying for available activity updates. Returns a list of updates available. Each list entry will have: (bundle_id, URL, download_size, current_installed_version_number, update_version_number). An optional parameter can be passed to trigger automatic upgrade to the new activities that are found.
	* GetDetails(bundle_id): For a given bundle_id already identified as an update, download and return the activity name (localised) and icon.		* GetDetails(bundle_id): For a given bundle_id already identified as an update, download and return the activity name (localised) and icon.
	* DoUpdate(bundle_id_1, bundle_id_2, ...): For the given bundle_ids already identified as updates, perform the activity update process (download, install).		* DoUpdate(bundle_id_1, bundle_id_2, ...): For the given bundle_ids already identified as updates and passed in as parameters, perform the activity update process (download, install).
	* StartAutomaticUpdate(): internally perform QueryUpdates() and then run DoUpdates() on all available updates. Returns immediately having kicked off the process internally.

	* Signal ActivityUpdating(bundle_id, download_size, download_completed, progress): Raised when an activity update is started, and then every 10 seconds until it is completed. The download_completed flag indicates whether the activity is downloading or installing, and the progress parameter indicates the percentage of the download or install.		* Signal ActivityUpdating(bundle_id, download_size, download_completed, progress): Raised when an activity update is started, and then every 10 seconds until it is completed. The download_completed flag indicates whether the activity is downloading or installing, and the progress parameter indicates the percentage of the download or install.
Line 82:		Line 81:
	This API is intended for internal use only.		This API is intended for internal use only.

	When Sugar wants to launch an automatic activity update, it will make a dbus method call to ~~StartAutomaticUpdate~~(), ~~which will return immediately having kicked off~~ an ~~activity update inside activity-updater~~.		When Sugar wants to launch an automatic activity update, it will make a dbus method call to FindUpdates(), requesting that an automatic upgrade is performed.

	When the user opens the "Software Update" section of the control panel, the control panel code will attempt to start listening to any ongoing update session. This means that if the user opens the control panel while an automatic update is happening in the background, that update effectively gets moved to the foreground, and the user can keep an eye on what is happening. If the control panel is opened while no update is active, the user will be able to launch a manually-invoked update in the way that the existing activity updater operates.		When the user opens the "Software Update" section of the control panel, the control panel code will attempt to start listening to any ongoing update session. This means that if the user opens the control panel while an automatic update is happening in the background, that update effectively gets moved to the foreground, and the user can keep an eye on what is happening. If the control panel is opened while no update is active, the user will be able to launch a manually-invoked update in the way that the existing activity updater operates.

	Activity installation/update will be done with the ~~Sugar~~ bundle ~~registry~~ API (~~jarabe.model.bundleregistry~~). ~~The activity updater will instantiate its own bundle registry object in its own process.~~		Activity installation/update will be done with the sugar-toolkit bundle API (like sugar-install-bundle). Sugar will become aware of these events through the way it already watches the filesystem. It might be worth addressing #3707 as part of this implementation effort so that this is fully reliable.

	Sugar will become aware of these events through the way it already watches the filesystem. ~~Ticket~~ #3707 ~~will be fixed~~ as part of this implementation effort so that this is fully reliable.

	== Future possibilities ==		== Future possibilities ==