Activities/Activity Library - Revision history

RafaelOrtiz: /* Ideas */

2011-05-31T04:34:25Z

Ideas

← Older revision		Revision as of 00:34, 31 May 2011
Line 5:		Line 5:
	== Ideas ==		== Ideas ==

	* ~~support~~ 0install by design		* Support 0install by design
	** use .xo format only if requested by user		** use .xo format only if requested by user
	** otherwise, activities should just start by click		** otherwise, activities should just start by click
Line 13:		Line 13:
	*** with 0launch (or with a special variant) it will be possible to run Library activities out of the ''Activity Library'' activity		*** with 0launch (or with a special variant) it will be possible to run Library activities out of the ''Activity Library'' activity

	* ~~support~~ forks		* Support forks
	** bundle_id should not be owned by any one developer. For the same bundle_id, there could be dozens of activities (and not only direct forks)		** bundle_id should not be owned by any one developer. For the same bundle_id, there could be dozens of activities (and not only direct forks)

	* no strict editors policy		* No strict editors policy
	** by default (or at least, there should be such an option), any user can launch any activity w/o additional steps (such as being logged in to ASLO)		** by default (or at least, there should be such an option), any user can launch any activity w/o additional steps (such as being logged in to ASLO)
	** there could be review profiles. A user could apply such a profile to disperse all activities to reviewing groups, e.g., Featured, Major, Trash etc.		** there could be review profiles. A user could apply such a profile to disperse all activities to reviewing groups, e.g., Featured, Major, Trash etc.
	** such profiles could be also created for particular deployment and tested by QA teams		** such profiles could be also created for particular deployment and tested by QA teams

	* ~~support~~ 0install stability profiles, e.g., Stable, Development, Buggy		* Support 0install stability profiles, e.g., Stable, Development, Buggy

	* ~~support~~ local user profile, e.g.,		* Support local user profile, e.g.,
	** use only Stable versions		** use only Stable versions
	** make my-favorite-developer's activities always show while using list		** make my-favorite-developer's activities always show while using list

	* ~~one~~ button click update, i.e., synchronize current activities with server's (taking into account		* One button click update, i.e., synchronize current activities with server's (taking into account

	* ~~provide~~ centralized stats that are easy-to-use by activity developers (option in activity.info), and easy-to-view by Activity Library users.		* Provide centralized stats that are easy-to-use by activity developers (option in activity.info), and easy-to-view by Activity Library users.
	** counting successful/failed launches by SP level, could be useful to judge activity stability		** counting successful/failed launches by SP level, could be useful to judge activity stability
	** tracking average duration of use or number of launches, etc.		** tracking average duration of use or number of launches, etc.

Alsroot: /* Ideas */

2010-05-06T04:33:42Z

Ideas

← Older revision		Revision as of 00:33, 6 May 2010
Line 32:		Line 32:
	** counting successful/failed launches by SP level, could be useful to judge activity stability		** counting successful/failed launches by SP level, could be useful to judge activity stability
	** tracking average duration of use or number of launches, etc.		** tracking average duration of use or number of launches, etc.

			* Integrate [[Collab mockup]] features
			** not all who share activities are activity developers

	=== Hierarchy of libraries ===		=== Hierarchy of libraries ===

FGrose: tune English

2010-04-30T13:33:44Z

tune English

← Older revision		Revision as of 09:33, 30 April 2010
Line 1:		Line 1:
	<noinclude>		<noinclude>{{TOCright}}
	~~{{GoogleTrans-en}}~~
	{{TOCright}}
	[[Category:Activities\|Library]]		[[Category:Activities\|Library]]
	</noinclude>		</noinclude>
Line 8:		Line 6:

	* support 0install by design		* support 0install by design
	** use .xo format only if user ~~requested .xo creating~~		** use .xo format only if requested by user
	** otherwise, activities should just start by click		** otherwise, activities should just start by click
	** activities will be represented by regular 0install feeds		** activities will be represented by regular 0install feeds
	*** more flexible dependency checking than on ASLO(only SP version), if activity requires recent gst to run, it just declares gst version		*** more flexible dependency checking than on ASLO (currently, only SP version), if activity requires a recent gst to run, it just declares that gst version
	*** variety of activity versions will be checked in runtime to detect what versions could be run on particular machine before launching		*** a variety of activity versions will be checked at runtime to detect what versions could be run on that particular machine before launching
	*** with 0launch (or with special ~~its~~ variant) will be possible to run Library activities out of ~~ActivityLibrary~~ activity		*** with 0launch (or with a special variant) it will be possible to run Library activities out of the ''Activity Library'' activity

	* support forks		* support forks
	** bundle_id should not be owned by ~~someone, for~~ the same bundle_id there could be dozens of activities (and not only direct forks)		** bundle_id should not be owned by any one developer. For the same bundle_id, there could be dozens of activities (and not only direct forks)

	* no strict editors policy		* no strict editors policy
	** by default (or at least there should be such option), any user can launch any activity w/o additional steps (~~like be~~ logged in on ASLO)		** by default (or at least, there should be such an option), any user can launch any activity w/o additional steps (such as being logged in to ASLO)
	** there ~~might~~ be review profiles, user ~~can~~ apply such profile to disperse all activities to ~~reviewed~~ groups e.g. Featured, Major, Trash etc.		** there could be review profiles. A user could apply such a profile to disperse all activities to reviewing groups, e.g., Featured, Major, Trash etc.
	** such profiles could be also created for particular deployment and tested by QA teams		** such profiles could be also created for particular deployment and tested by QA teams

	* support 0install stability profiles e.g. Stable, Development, Buggy		* support 0install stability profiles, e.g., Stable, Development, Buggy

	* support local user profile e.g.		* support local user profile, e.g.,
	** use only Stable versions		** use only Stable versions
	** make my-favorite-developer's activities ~~all time in~~ using list		** make my-favorite-developer's activities always show while using list

	* one button click update i.e. synchronize current activities w/ server's (taking into account		* one button click update, i.e., synchronize current activities with server's (taking into account

	* provide easy to use by activity developers (option in activity.info) and easy to view by ~~Actiivty~~ Library users~~, centralized stats~~		* provide centralized stats that are easy-to-use by activity developers (option in activity.info), and easy-to-view by Activity Library users.
	** successful/failed ~~launch of what~~ SP, could be useful to judge activity stability		** counting successful/failed launches by SP level, could be useful to judge activity stability
	** average ~~time~~ of ~~using/~~number of launches/etc		** tracking average duration of use or number of launches, etc.

	=== Hierarchy of libraries ===		=== Hierarchy of libraries ===
Line 57:		Line 55:
	== Related resources ==		== Related resources ==

	* [[~~Collab_mockup~~]]		* [[Collab mockup]]

	== TODO ==		== TODO ==

	* merge [[Features/~~Zero_Sugar_Activities~~]] with this page		* merge [[Features/Zero Sugar Activities]] with this page

Alsroot: /* Ideas */

2010-04-30T12:37:46Z

Ideas

← Older revision		Revision as of 08:37, 30 April 2010
Line 21:		Line 21:
	** by default (or at least there should be such option), any user can launch any activity w/o additional steps (like be logged in on ASLO)		** by default (or at least there should be such option), any user can launch any activity w/o additional steps (like be logged in on ASLO)
	** there might be review profiles, user can apply such profile to disperse all activities to reviewed groups e.g. Featured, Major, Trash etc.		** there might be review profiles, user can apply such profile to disperse all activities to reviewed groups e.g. Featured, Major, Trash etc.
			** such profiles could be also created for particular deployment and tested by QA teams

	* support 0install stability profiles e.g. Stable, Development, Buggy		* support 0install stability profiles e.g. Stable, Development, Buggy

Alsroot: /* Hierarchy of libraries */

2010-04-30T12:32:56Z

Hierarchy of libraries

← Older revision		Revision as of 08:32, 30 April 2010
Line 53:		Line 53:
	> * shares his Activity_Library instance		> * shares his Activity_Library instance
	> * any joined user can see\|download\|launch these activities		> * any joined user can see\|download\|launch these activities

			== Related resources ==

			* [[Collab_mockup]]

			== TODO ==

			* merge [[Features/Zero_Sugar_Activities]] with this page

Alsroot: /* Ideas */

2010-04-30T12:26:22Z

Ideas

← Older revision		Revision as of 08:26, 30 April 2010
Line 13:		Line 13:
	*** more flexible dependency checking than on ASLO(only SP version), if activity requires recent gst to run, it just declares gst version		*** more flexible dependency checking than on ASLO(only SP version), if activity requires recent gst to run, it just declares gst version
	*** variety of activity versions will be checked in runtime to detect what versions could be run on particular machine before launching		*** variety of activity versions will be checked in runtime to detect what versions could be run on particular machine before launching
			*** with 0launch (or with special its variant) will be possible to run Library activities out of ActivityLibrary activity

	* support forks		* support forks

Alsroot: /* Ideas */

2010-04-30T09:46:06Z

Ideas

← Older revision		Revision as of 05:46, 30 April 2010
Line 11:		Line 11:
	** otherwise, activities should just start by click		** otherwise, activities should just start by click
	** activities will be represented by regular 0install feeds		** activities will be represented by regular 0install feeds
	*** more flexible dependency checking ~~then~~ on ASLO(only SP version), if activity requires recent gst to run, it just ~~declare~~ gst version~~(like regular 0install feeds)~~		*** more flexible dependency checking than on ASLO(only SP version), if activity requires recent gst to run, it just declares gst version
	**** variety of activity versions will be checked in runtime to detect what versions could be run on particular machine		*** variety of activity versions will be checked in runtime to detect what versions could be run on particular machine before launching

	* support forks		* support forks

Alsroot: /* Ideas */

2010-04-30T09:43:56Z

Ideas

← Older revision		Revision as of 05:43, 30 April 2010
Line 10:		Line 10:
	** use .xo format only if user requested .xo creating		** use .xo format only if user requested .xo creating
	** otherwise, activities should just start by click		** otherwise, activities should just start by click
			** activities will be represented by regular 0install feeds
			*** more flexible dependency checking then on ASLO(only SP version), if activity requires recent gst to run, it just declare gst version(like regular 0install feeds)
			**** variety of activity versions will be checked in runtime to detect what versions could be run on particular machine

	* support forks		* support forks

Alsroot: /* Ideas */

2010-04-29T15:07:52Z

Ideas

← Older revision		Revision as of 11:07, 29 April 2010
Line 29:		Line 29:
	** successful/failed launch of what SP, could be useful to judge activity stability		** successful/failed launch of what SP, could be useful to judge activity stability
	** average time of using/number of launches/etc		** average time of using/number of launches/etc

			=== Hierarchy of libraries ===

			On Thu, Apr 29, 2010 at 01:58:34PM +0000, Aleksey Lim wrote:
			> On Thu, Apr 29, 2010 at 08:46:06AM -0400, Bernie Innocenti wrote:
			> > Will it support multiple libraries, for the same of decentralizing
			> > things?
			> >
			> > I can imagine that many deployments would want a hierarchical thing to
			> > save bandwidth and delegate decisions to school principals: the
			> > schoolserver would be the first place where children search for
			> > activities, then would come the deployment server and lastly ASLO.
			>
			> Thanks, this hierarchical structure will be useful not only on pure
			> server side but on peers side as well, like:
			>
			> * someone added bunch of cool activities to his list (w/o
			> downloading\|launching them)
			> * shares his Activity_Library instance
			> * any joined user can see\|download\|launch these activities

Alsroot: Created page with ' {{GoogleTrans-en}} {{TOCright}} Library == Ideas == * support 0install by design ** use .xo format only if user requested .xo c…'

2010-04-29T15:01:32Z

Created page with '<noinclude> {{GoogleTrans-en}} {{TOCright}} Library </noinclude> == Ideas == * support 0install by design ** use .xo format only if user requested .xo c…'

New page

<noinclude>
{{GoogleTrans-en}}
{{TOCright}}
[[Category:Activities|Library]]
</noinclude>

== Ideas ==

* support 0install by design
** use .xo format only if user requested .xo creating
** otherwise, activities should just start by click

* support forks
** bundle_id should not be owned by someone, for the same bundle_id there could be dozens of activities (and not only direct forks)

* no strict editors policy
** by default (or at least there should be such option), any user can launch any activity w/o additional steps (like be logged in on ASLO)
** there might be review profiles, user can apply such profile to disperse all activities to reviewed groups e.g. Featured, Major, Trash etc.

* support 0install stability profiles e.g. Stable, Development, Buggy

* support local user profile e.g.
** use only Stable versions
** make my-favorite-developer's activities all time in using list

* one button click update i.e. synchronize current activities w/ server's (taking into account

* provide easy to use by activity developers (option in activity.info) and easy to view by Actiivty Library users, centralized stats
** successful/failed launch of what SP, could be useful to judge activity stability
** average time of using/number of launches/etc