Difference between revisions of "Activities/Activity Library"

From Sugar Labs
Jump to navigation Jump to search
 
(6 intermediate revisions by 2 users not shown)
Line 1: Line 1:
−
<noinclude>
+
<noinclude>{{TOCright}}
−
{{GoogleTrans-en}}
 
−
{{TOCright}}
 
 
[[Category:Activities|Library]]
 
[[Category:Activities|Library]]
 
</noinclude>
 
</noinclude>
Line 7: Line 5:
 
== Ideas ==
 
== Ideas ==
  
−
* 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 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 (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
+
*** 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
+
* 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
  
−
* 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.
 +
 
 +
* Integrate [[Collab mockup]] features
 +
** not all who share activities are activity developers
  
 
=== Hierarchy of libraries ===
 
=== Hierarchy of libraries ===
Line 52: Line 55:
 
  > * 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

Latest revision as of 23:34, 30 May 2011


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

Retrieved from "https://wiki.sugarlabs.org/index.php?title=Activities/Activity_Library&oldid=66118"