Difference between revisions of "Activities/Activity Library"
Jump to navigation
Jump to search
(→Ideas) |
(tune English) |
||
Line 1: | Line 1: | ||
− | <noinclude> | + | <noinclude>{{TOCright}} |
− | |||
− | {{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 | + | ** 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 | + | *** 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 | + | *** 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 | + | ** 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 ( | + | ** 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 | + | ** 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 | + | ** make my-favorite-developer's activities always show while using list |
− | * one button click update i.e. synchronize current activities | + | * 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 | + | * 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 | + | ** counting successful/failed launches by SP level, could be useful to judge activity stability |
− | ** average | + | ** 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]] |
== TODO == | == TODO == | ||
− | * merge [[Features/ | + | * merge [[Features/Zero Sugar Activities]] with this page |
Revision as of 08:33, 30 April 2010
Ideas
- support 0install by design
- use .xo format only if requested by user
- otherwise, activities should just start by click
- activities will be represented by regular 0install feeds
- 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
- 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 a special variant) it will be possible to run Library activities out of the Activity Library activity
- 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)
- 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)
- 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
- 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 always show while using list
- 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.
- counting successful/failed launches by SP level, could be useful to judge activity stability
- tracking average duration of use or 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
Related resources
TODO
- merge Features/Zero Sugar Activities with this page