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

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

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