Activities/Activity Library

From Sugar Labs
Jump to navigation Jump to search
The printable version is no longer supported and may have rendering errors. Please update your browser bookmarks and please use the default browser print function instead.


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.
  • Integrate Collab mockup features
    • not all who share activities are activity developers

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