Line 29: |
Line 29: |
| ** successful/failed launch of what SP, could be useful to judge activity stability | | ** successful/failed launch of what SP, could be useful to judge activity stability |
| ** average time of using/number of launches/etc | | ** 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 |