On Jul 26, 2016 4:12 PM, "Sebastian Silva" <<a href="mailto:sebastian@fuentelibre.org">sebastian@fuentelibre.org</a>> wrote: > > El 26/07/16 a las 14:05, Dave Crossland escribió: >> >> >> On Jul 26, 2016 2:36 PM, "Sebastian Silva" <<a href="mailto:sebastian@fuentelibre.org">sebastian@fuentelibre.org</a>> wrote: >> > >> > El 26/07/16 a las 13:08, Dave Crossland escribió: >> >> >> >> Despite my suggestion to look at zeromq, I think we should be using the collaboration protocols that Lionel is using in Sugarizer, so that someone running Sugar desktop and someone using Sugarizer on a Chromebook (for example, 2 kids in a family at home who attend 2 different schools that have different hardware purchasing decisions ;) could collaborate. >> > >> > It's not a dichotomy. >> > >> > If two users use the same app [and it supports collaboration] - it should just work regardless of the environment where they are run. >> > >> > Much like running etherpad @ titanpad. >> >> I mean to propose a requirement for any new collaboration system that is recommended to all sugar developers be that it support collaboration between a python paint application and a Javascript paint application. > > That sounds challenging and not too useful. > >> And therefore the system that meets that requirement is the one used by sugarizer today. Why could using the system on sugarizer from python be more challenging than writing a new system with zeromq or similar? :) >> >> However, I am eagerly awaiting Sameer's next installment of the vision quest process, because without the vision/mission/etc defined, we can't make informed technical decisions about what kind of collaboration protocols are best. >> > >> > >> > Maybe we shouldn't have to judge - they can all coexist. >> >> An anti-design approach where no system is recommended and each activity developer can figure out their own system seems counter to the aims of a cohesive and consistent learning platform in which collaboration is promoted as a top tier feature :) > > User facing features are at the application level. How they are implemented is only a detail. I'd rather have a paint app that collaborates, no matter how it is built. Currently we have none. The technology that Sugar platform offers to activity developers is what determines if they implement collaboration as a user facing feature. It seems to me that the current platform recommendation is for something that was experimental 10 years ago and has not matured in this time, so I am not surprised to hear central apps like paint don't implement features with it. > It is part of our philosophy to promote collaboration - at all levels - open organizations, user freedom, git, wiki, etc. Right - so I think its worth considering the strategic context of the implementation details: )