Activities/Activity Library

Ideas

support 0install by design
- use .xo format only if user requested .xo creating
- otherwise, activities should just start by click
- 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
  - 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
- 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.
- 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 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

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

Collab_mockup

TODO

merge Features/Zero_Sugar_Activities with this page