Hi all, (be careful, pathos content:)
I'm going to post about my sugar vision(not only about technical cases) which I'm going to implement during 0.88 release cycle(though non of these points are tight to sucrose releases). The major point of some of my proposals to 0.88 sucrose has social context(how I understand sugar's social benefits). One of idea I had in mind from beginning about sugar is that sugar is not a "product"(like GNOME for example) but permanently changing tool which lets its (not users)doers create masterpieces(including sugar itself). So, I have strong intension to switching development focus from core team, which develops sucrose - glucose(core) and fructose(some core activities) to wide range of developers/doers thus some kind of decentralization of development process. I think I've found proper way - instead of decentralising technical aspects in core development, decentralise method of sharing changes between users/doers - here Zero Install[1] integration[2] - integration not to shell UI or other technical aspects but to sugar community. Someone can say that this decentralization splits sugar community but see previous text about "product", only "product" producer cares about centralizing(mostly about centralizing profits:) but I'm strongly for many forks/(re)implementations/etc of sugar, in my mind this situation meets the final target of sugar - constructive thinking of (not users)doers. What I'm personally going to do in previously mentioned process is taking part in Zero Install[1] integration to SL services like Activity Library[3], bugs tracker, files servers etc. Technical benefits of Zero Install integration: * let activity developers include not only Sugar Platform[4] GNU/Linux distribution dependencies, 0install let(will, after PackageKit integration, I'm planing to complete this week) install such dependencies by demand * exclude binary blobs from .xo bundles at all, proper dependencies could be installed 1) from native packages 2) from 0install binary packages 3) and finally could be build on user side from sources * having non sucrose shared libraries(like sugargames) that develops won't have to bundle to .xos and benefit from 0install updating process * one of consequences of previous case is that now its possible to start switching to service provider model for sugar core[5], when activity developers should not be stuck to particular sucrose release(which has 6 months cycle - too short for field deployments) and be stuck to API of services they use. Sufficient services could be installed/updated by demand via 0install infrastructure. Also social benefits: * I'm planing to implement sucrose release agnostic library(which will be a service installed/updated via 0install) to launch sugar activities(w/o any support from activity developers) in non sugar environment. So, this feature will merge non sugar and sugar communities - if teacher wants use TurtleArt activity in existed(nont-sugar) environment in classroom, he can just install(via 0install) TurtleArt from Activity Library and will get the same activity like it looks in native sugar * I hope to see many shell forks with implemented features like new sugar themes(wallpapers support, new icons etc.), Actions view implementations from non-core development/doers. The benefit they will have after 0install integration is more useful method to share these forks - just a regular entity on Activity Library that brings new shell to user environment(new shell Instance won't remove system installed shell, so users will have easy method to back switch to previous shell) [1] http://0install.net/ [2] http://wiki.sugarlabs.org/go/Zero_Install_integration [3] http://activities.sugarlabs.org/ [4] http://wiki.sugarlabs.org/go/0.86/Platform_Components [5] http://wiki.sugarlabs.org/go/Features/Decoupling_of_Sucrose -- Aleksey _______________________________________________ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel