[Sugar-devel] What is a blocker bug today?
Why is this bug marked as Blocker? http://dev.sugarlabs.org/ticket/199 Traditionally, we made Blocker mean that a XOOS release must wait for it to be fixed. Now that we have multiple downstreams, we might want to rethink the semantics to mean no sucrose release until all blockers are fixed, or something like that. I'd also like to discuss how our time-based releases relate with the need to fix all blockers before a release. -- // Bernie Innocenti - http://www.codewiz.org/ \X/ Sugar Labs - http://www.sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Soas Distribution/OS
On Feb 2, 2009, at 1:20 AM, Bernie Innocenti wrote: Simon Schampijer wrote: Marco Pesenti Gritti wrote: Can we add Soas as one of the field alternatives? Couldn't quickly figure out how to do it myself... Yeah the admin interface does not seem to let you change the custom fields we added to the trac.ini :/ Bernie you might be able to do it quickly, thanks. Done, although not quickly, sorry. The Distribution/OS is in the section [ticket-custom] of trac.ini, and admittedly the web interface does not provide a way to edit it. Maybe Noah knows why? No one ever got around to making a web UI for it. There is a plugin I can install if you would like. --Noah ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Soas Distribution/OS
Bernie Innocenti wrote: Simon Schampijer wrote: Marco Pesenti Gritti wrote: Can we add Soas as one of the field alternatives? Couldn't quickly figure out how to do it myself... Yeah the admin interface does not seem to let you change the custom fields we added to the trac.ini :/ Bernie you might be able to do it quickly, thanks. Done, although not quickly, sorry. Sorry, did not mean to rush you - meant quickly as in you have the easiest access to the ini file. Anyhow, thanks. Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Soas Distribution/OS
Simon Schampijer wrote: Bernie Innocenti wrote: Simon Schampijer wrote: Marco Pesenti Gritti wrote: Can we add Soas as one of the field alternatives? Couldn't quickly figure out how to do it myself... Btw, i guess we should move now all the Bugs that are filed under the SoaS component and tag them SoaS Distribution and remove the SoaS component, or? Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Aside: Neighborhood participants
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Morgan Collett wrote: Also don't blame avahi for the fact that we send out updates every time you alt-tab between shared activities, so that your icon can jump to the appropriate snowflake on everyone else's Neighborhood Views... I _strongly_ object to this behavior. Not only is this flooding the mesh with useless broadcasts, but it provides exactly the _wrong_ result in the UI. When I look at the Neighborhood view, I want to see who is participating in each shared instance. Instead, the view shows me who is in that particular window at this time. It's as if IRC clients only showed you as present in the room that is currently visible on your screen. We should remove this feature and instead show each person in the ring around each activity they have joined. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmHIr0ACgkQUJT6e6HFtqSr6QCfVIKVafX44TFETpmNao8mGevr ldUAoJ+q09kT87G/PzJDdT2ND3HzE0Fl =yxQR -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Soas Distribution/OS
Marco Pesenti Gritti wrote: On Mon, Feb 2, 2009 at 5:44 PM, Simon Schampijer si...@schampijer.de wrote: Btw, i guess we should move now all the Bugs that are filed under the SoaS component and tag them SoaS Distribution and remove the SoaS component, or? I think we should keep the component. SoaS should probably have his own bug system but... it's just overkill for now. The Distribution bit is for upstream bugs that was found on SoaS. Marco I guess many bugs that are filed under the component SoaS are currently upstream ones. We should be paying attention to triage them right. Regards, Simon ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [OBORONA-SPAM] Re: sugar-widgets request
On Mon, Feb 02, 2009 at 01:13:58PM +0100, Tomeu Vizoso wrote: On Mon, Feb 2, 2009 at 13:11, Aleksey Lim alsr...@member.fsf.org wrote: On Mon, Feb 02, 2009 at 11:08:11AM +0100, Tomeu Vizoso wrote: On Mon, Feb 2, 2009 at 02:32, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, While tweaking/hacking some activities I have to, from time to time, copypaste code between activities. Sometime it works well: tempo slider from TamTam activities means 20-30 lines and 5-7 images. Now (for Speak activity) I need ChatBox widget from Chat and it costs 400 lines. Its a good idea to support those 400 lines in one repo. Whats the right place for it? And in common, should we collect such widgets/libraries in one place, sugar-toolkit? new project sugar-widgets? A new project seems like more work for both upstream developers and packagers. Any downsides if we put them in sugar-toolkit? I'm thinking about activity API based package, in fact sugar-toolkit doesn't fit to that role, since sugar-toolkit itself provides that API. Sorry, can you rephrase? Don't understand what you meant here. I mean new sugar-widgets package should use only public activity API, something like a current-sugar's-version-independent link between sugar and activities (mostly honey activities). -- Aleksey ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] [OBORONA-SPAM] Re: sugar-widgets request
On Mon, Feb 2, 2009 at 5:49 PM, Aleksey Lim alsr...@member.fsf.org wrote: I mean new sugar-widgets package should use only public activity API, something like a current-sugar's-version-independent link between sugar and activities (mostly honey activities). That's pretty much what sugar-toolkit is supposed to be though... My main concern is API stability policy for this code. It's going to be difficult to maintain large new API stable... especially if they are initially just cut and paste from activities. GNOME deals with having an egg module from which applications can cut/paste, which has his downsides too. Marco ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Aside: Neighborhood participants
On 2 Feb 2009, at 16:43, Benjamin M. Schwartz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Morgan Collett wrote: Also don't blame avahi for the fact that we send out updates every time you alt-tab between shared activities, so that your icon can jump to the appropriate snowflake on everyone else's Neighborhood Views... I _strongly_ object to this behavior. Not only is this flooding the mesh with useless broadcasts, but it provides exactly the _wrong_ result in the UI. When I look at the Neighborhood view, I want to see who is participating in each shared instance. Instead, the view shows me who is in that particular window at this time. It's as if IRC clients only showed you as present in the room that is currently visible on your screen. +1 We should remove this feature and instead show each person in the ring around each activity they have joined. However there are some interesting UI design issues (). XO buddy icons are currently unique identities, this will lead to your icons being in multiple places in the neighbourhood (and group) view (on each shared activity). More icons mean less space... Have you seen ~30-40 buddies on a jabber server? Wow it's crowded as is, let's hope gadget and smart filters work well. i.e see who you want by default and be able to easily find those gadget decides to hide from you... Actually I can almost see this being a case for replacing the neighbourhood with just custom smart groups UI; you start with some reasonable default gadget filter; then create new groups for your different needs (perhaps a maths class group, a friends group, a pen-pals group, an artists group etc). Maybe the neighbourhood view ends up pretty much just showing icons for subgroups. An interesting design challenge, especially trying to keep the zoom metaphor consistant... --Gary - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmHIr0ACgkQUJT6e6HFtqSr6QCfVIKVafX44TFETpmNao8mGevr ldUAoJ+q09kT87G/PzJDdT2ND3HzE0Fl =yxQR -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] A small request.
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Feb 02, 2009 at 07:25:54AM -0500, C. Scott Ananian wrote: On Mon, Feb 2, 2009 at 6:46 AM, Jonas Smedegaard d...@jones.dk wrote: On Mon, Feb 02, 2009 at 10:46:35AM +0100, Bernie Innocenti wrote: C. Scott Ananian wrote: OK, thanks. The existing updater works fine in Debian; I don't know if it was ever pushed into koji, but it is certainly compatible with Fedora. Are you talking about official Sugar packages installed on pure Debian (unstable or testing branch)? I am talking about the debian packages specified by the 'debian' directory in the source repositories for sugar-update-control and olpc-contents, which is how I developed and tested the updater on my debian/unstable box. ok - makes much more sense to me now. Packaging Sugar officially for Debian and derivatives And thanks so much for that! Oh, well - thanks to you guys for the (huge) rest of the work involved! - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmG8X8ACgkQn7DbMsAkQLi12ACfUDBKeX9hcC3ur+ONFsuG2B3E uY4An3yxyhR52bjexgebw9Guj8E0mWVX =C4ED -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] A small request.
Bernie Innocenti wrote: Another issue is how we integrate the updater with addons.sl.o. Because the OLPC microformat is trivial, it might be easy to modify the remora's html output to be compatible with it. Mick, Tomeu and David, who have had a closer look at the code, might want to comment. If you have no idea what this OLPC microformat is, here's the format specification as was originally documented by C.Scott. -cut- Activity information microformat parser. Activity information is embedded in HTML/XHTML/XML pages using a semantic `microformat http://microformats.org/`_. The following CSS rules pull out the desired information. Repository/group information for related activities is denoted by the `CSS http://www.w3.org/Style/CSS/`_ selector:: #olpc-activity-group-name which provides a short name for the group, and:: #olpc-activity-group-desc which provides a slightly longer description. As indicated by the fact that these are matches on the 'id' attribute, they should match exactly once. These attributes are optional, and are not expected to be included in pages describing updates for an individual activity. Each block of activity information is denoted by the selector:: .olpc-activity-info All information within that block describes a single available version of an activity, so the following selectors should match at most once within the block. The activity id, which should be unique among all activities, is denoted by the contents of the element identified by the selector:: .olpc-activity-info .olpc-activity-id The version number is denoted by the contents of the element identified by the selector:: .olpc-activity-info .olpc-activity-version The version URL is denoted by the contents of the href attribute of the element identified by the selector:: .olpc-activity-info .olpc-activity-url *[href] An example:: table class=olpc-activity-info tr tdBrowse/td td class=olpc-activity-id style=display:none;org.laptop.WebActivity/td td class=olpc-activity-version54/td td class=olpc-activity-urla href=Browse-54.xodownload!/a/td /td /table -cut- -- // Bernie Innocenti - http://www.codewiz.org/ \X/ Sugar Labs - http://www.sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] A small request.
On Mon, Feb 2, 2009 at 8:56 AM, Ties Stuij cjst...@gmail.com wrote: On Mon, Feb 2, 2009 at 11:23 AM, C. Scott Ananian csc...@laptop.org wrote: On Sun, Feb 1, 2009 at 9:24 PM, Martin Langhoff martin.langh...@gmail.com wrote: So this depends on a simple service-announcement scheme. I'll sidestep the how of it, and say: When Sugar knows that there is a local activity install/update server, then the activity updater it _must_ try against the local service first. I still believe the proper way to do this is to have a local offline cache. The protocol was explicitly designed to be easily cacheable. But it probably wouldn't be hard to add an override URL to the current lookup routine, which is always checked first. You'd have to add the activity id somehow to generate the full url. You could set a the override URL in the sugar configuration. I don't think this is the right thing (why are we still having trouble getting caching working right?) but (as Michael suggested in the initial mail on this thread) I'm perfectly happy supporting more than one way to do it if someone thinks this will help a specific deployment. --scott Huh? Well it depends on what you guys want to accomplish I guess, and C. Scott wrote the code I believe, but as I understand it, this functionality is already present. In any case if you supply an /etc/olpc-update/activitiy-groups file pointing to your local schoolserver, it will override the default url and update without any qualms. I just tested this just to be sure, without internet-connection, and it went swimmingly. As for the url supplied by the activity itself, It's my opinion that it shouldn't be used at all. As per my entry in the activity update thread. By chosing whether to use pinning, the administrator has the option of not using the url supplied by the activity itself. Otherwise I agree completely. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Service announcement scheme - (Re: A small request.)
On Mon, Feb 2, 2009 at 8:58 AM, Bernie Innocenti ber...@laptop.org wrote: Morgan Collett wrote: Also don't blame avahi for the fact that we send out updates every time you alt-tab between shared activities, so that your icon can jump to the appropriate snowflake on everyone else's Neighborhood Views... as well as sending who joined and left... Mature GUIs have a common pattern to avoid too much graphical flickering on possibly rapid state transitions, such as setting a busy pointer or disabling buttons while some operation is in progress. I don't know if it has a name, but the algorithm is exactly the same for de-bouncing mechanical keys: you propagate the event only after the state has settled for a certain amount of time. This would take away a certain percentage of spurious updates, but the number basically remains proportional to the number of users so it doesn't scale much better. http://wiki.laptop.org/go/Network_architecture#Direct_presence_interrogation describes an algorithm to ensure that the amount of traffic in the net is kept proportional to the number of users. (The algorithm you describe is actually proportional to the number of users squared or cubed, because the size of the messages as well as the number of such messages increases with the # of users. If a mesh network is involved, the number of rebroadcasts necessary is another factor roughly proportional to the size of the network.) --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] #104 MAJO: [Trac] Bug reporting tickets don't ask for enough information to pinpoint the software versions in use.
I don't know. That's up to your debugging team members. I just submitted a new bug report. I see the version field which allows values for the Sugar version used. Stan -- On Sun, Feb 1, 2009 at 3:37 AM, SugarLabs Bugs bugtracker-nore...@sugarlabs.org wrote: #104: [Trac] Bug reporting tickets don't ask for enough information to pinpoint the software versions in use. -+-- Reporter: overbyte | Owner: erikos Type: defect| Status: assigned Priority: major | Milestone: 0.84 Component: sugar |Version: Severity: Major | Resolution: Keywords:| Distribution: Unspecified Status_field: Needinfo | -+-- Changes (by tomeu): * distribution: = Unspecified * status_field: = Needinfo * severity: = Major * milestone: = 0.84 Comment: overbyte, could you please check your suggestions were correctly addressed? Thanks! -- Ticket URL: http://dev.sugarlabs.org/ticket/104#comment:3 Sugar Labs http://sugarlabs.org/ Sugar Labs bug tracking system ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Service announcement scheme - (Re: A small request.)
On Mon, Feb 2, 2009 at 5:13 AM, Bernie Innocenti ber...@laptop.org wrote: Martin Langhoff wrote: On Mon, Feb 2, 2009 at 6:39 PM, C. Scott Ananian csc...@laptop.org wrote: My suggestions: DNS-SD and libepc (http://live.gnome.org/libepc/). There's no need for Sugar-specific solutions here; we just need to use existing standard solutions. Yep - I want existing standard stuff, but the devil we know seems to swamp the spectrum with 802.11s. When I read the Zeroconf book, I got the impression that the _standard_ was carefully designed to minimize needless broadcasts and scale well in real scenarios. I can't comment on the current Avahi _implementation_ though. This is true for wired networks; not necessarily true for mobile and/or wireless networks. Like Martin, you are confusing mDNS with DNS-SD. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Service announcement scheme - (Re: A small request.)
On Tue, Feb 3, 2009 at 1:17 AM, C. Scott Ananian csc...@laptop.org wrote: http://ieeexplore.ieee.org/Xplore/login.jsp?url=/iel5/4489030/4489031/04489571.pdf?temp=x I don't want adventure. I want something old and safe ;-) Maybe we can fake this with good old DNS lookups - but those will fail if the DNS server has a wildcard (like commercial hotspots do). I think you are confusing mDNS with DNS-SD. Perhaps. The paper abstract mentions both, and seems to say that the solution is with DNS-SD+new software. There's another paper from the same authors that talks about saturation in mesh networks. I'd like to read that paper (anyone got access to IEEE pubs?) . In fact, I'd like to find that someone has implemented DNS-SD on 802.11s networks and had a raging success. I want it simple and safe :-) cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity updater
On Mon, Feb 2, 2009 at 7:00 AM, Bernie Innocenti ber...@sugarlabs.org wrote: Jonas Smedegaard wrote: What Debian package? I found no mention of olpc-update anywhere in the source code for Sugar, so I guess you are talking about something OLPC-specific _below_ Sugar, right? olpc-update is the official updater for the core OS of the OLPC distribution. It is very XOOS specific so you probably don't want to package it for Debian. Not true at all, FWIW. Are you packaging up the sugar-update-control package for Debian? It's here: http://dev.laptop.org/git?p=users/cscott/sugar-update-control;a=summary (I don't know if release tarballs exist for it) gitweb provides tarballs corresponding to tagged releases. My tentative plan, to be further discussed here, is: 1. import the project in gitorious; 2. break the dependency with olpc-update and bitfrost; There's only a weak dependency on the 'inhibit-suspect' functionality in olpc-update; it's already wrapped in a try block so if olpc-update isn't installed, nothing bad happens (except on an XO, when suspend won't be properly inhibited, natch). 3. add it to jhbuild; 4. get the RPM accepted in Fedora; 5a. change the default URL to point at an Activities page on the Sugar Labs wiki. or, 5b. modify addons.sl.o to understand the OLPC microformat. The choice between 5a or 5b depends on the amount of progress we do with remora over the next few weeks. IMO, rather than worry about 5a, you should just endeavor to ensure that all sugarlabs packaged activites have an appropriate update_url that points to the sugarlabs wiki. The default is just for legacy compatibility. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] What is a blocker bug today?
On Mon, Feb 2, 2009 at 09:44, Bernie Innocenti ber...@codewiz.org wrote: Why is this bug marked as Blocker? http://dev.sugarlabs.org/ticket/199 I would say it's a blocker because that's the default value for that field and the first person who modified the ticket (Marco) after those fields were set up didn't explicitly set a different value. So not really a blocker, just a mistake. Regards, Tomeu Traditionally, we made Blocker mean that a XOOS release must wait for it to be fixed. Now that we have multiple downstreams, we might want to rethink the semantics to mean no sucrose release until all blockers are fixed, or something like that. I'd also like to discuss how our time-based releases relate with the need to fix all blockers before a release. -- // Bernie Innocenti - http://www.codewiz.org/ \X/ Sugar Labs - http://www.sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] A small request.
On Tue, Feb 3, 2009 at 1:20 AM, C. Scott Ananian csc...@laptop.org wrote: I don't understand your problem. How does the XS know what URLs to mask? For example, say the current version of Foo.xo (which the XS has) has a url of http://sugarlabs.org/activities/ in its metadata but _old_ versions of the same activity are set to http://wiki.laptop.org/go/Activities/ . - Should Foo.xo metadata contain a growing history of all urls for the XS to intercept? - Should the XS contain a growing cheatsheet of urls to intercept? - For laptop.org - SL is easy, how about all the other activity authors using random personal servers? All this specialcasing and cheat-sheet exceptions on the XS is just plain horrible. And only ever works with HTTP. Se do need a service discovery means for anything that is not as amenable to abuse as HTTP. m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Service announcement scheme - (Re: A small request.)
On Feb 2, 2009, at 4:21 PM, Martin Langhoff wrote: 'd like to read that paper (anyone got access to IEEE pubs?) http://radian.org/~krstic/krebs-sd.pdf -- Ivan Krstić krs...@solarsail.hcs.harvard.edu | http://radian.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugar-widgets request
On Mon, Feb 2, 2009 at 02:32, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, While tweaking/hacking some activities I have to, from time to time, copypaste code between activities. Sometime it works well: tempo slider from TamTam activities means 20-30 lines and 5-7 images. Now (for Speak activity) I need ChatBox widget from Chat and it costs 400 lines. Its a good idea to support those 400 lines in one repo. Whats the right place for it? And in common, should we collect such widgets/libraries in one place, sugar-toolkit? new project sugar-widgets? A new project seems like more work for both upstream developers and packagers. Any downsides if we put them in sugar-toolkit? Regards, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] A small request.
C. Scott Ananian wrote: OK, thanks. The existing updater works fine in Debian; I don't know if it was ever pushed into koji, but it is certainly compatible with Fedora. If anyone wants to develop a new updater, I can probably offer some advice. Using an explicit update_url field in the activity is recommended for activities packaged with the current updater; the OLPC wiki default was only ever intended to be a bridge for legacy apps, not a recommended practice. I prefer email for initial discussions of updater ideas: 9am isn't a great meeting time for me. How did the Debian package cope with the dependency on olpc-update? I thought we had to break that and integrate the relevant support files in the control panel module. Another issue is how we integrate the updater with addons.sl.o. Because the OLPC microformat is trivial, it might be easy to modify the remora's html output to be compatible with it. Mick, Tomeu and David, who have had a closer look at the code, might want to comment. With a web UI similar to addons.mozilla.org, the local UI for browsing new activities becomes redundant and could be culled, reducing the control panel module to a mere updater. I guess this is for the UI designers to decide. See also: http://sugarlabs.org/go/ActivityTeam/Remora_port http://sugarlabs.org/go/DevelopmentTeam/a.s.o http://people.sugarlabs.org/dfarning/aslo_patches/ http://cananian.livejournal.com/48460.html also has some thoughts on updaters. Regarding the integration with PackageKit, long-term that would be the best course, but since it would take a big rewrite I doubt it can happen within the 0.84 time frame. Unless someone else steps up, I volunteer to do the minimum necessary integration work to make the current updater work in SoaS with addons.sl.o as a backend. -- // Bernie Innocenti - http://www.codewiz.org/ \X/ Sugar Labs - http://www.sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity updater
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Feb 02, 2009 at 01:00:53PM +0100, Bernie Innocenti wrote: Jonas Smedegaard wrote: What Debian package? I found no mention of olpc-update anywhere in the source code for Sugar, so I guess you are talking about something OLPC-specific _below_ Sugar, right? olpc-update is the official updater for the core OS of the OLPC distribution. It is very XOOS specific so you probably don't want to package it for Debian. Thanks for clarifying. Are you packaging up the sugar-update-control package for Debian? It's here: http://dev.laptop.org/git?p=users/cscott/sugar-update-control;a=summary (I don't know if release tarballs exist for it) No. Might do in the future. No problem for Debian that it is distributed separately from core Sugar - - on the contrary, this makes it easier to eventually backport to older releases of Sugar. - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmG4woACgkQn7DbMsAkQLjBTACghihw/44gIcTORU54RuqC6ad2 C5UAn1ZYm8sj/TsBq52ueG8OR65Kcify =w1ly -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] A small request.
On Tue, Feb 3, 2009 at 10:50 AM, Gary C Martin g...@garycmartin.com wrote: pull it back on list), but while trying to follow this thread I'd been assuming one of the XS functions is as an http proxy cache server (squid or some such). This wouth then help reduce common internet traffic via caching; one person downloads new version of TurtleArt, it's sitting in cache for the rest of the class/school. Oh, yes it does have an http proxy (and yours is a good question). However, think about an XS that has no internet connection or an incredibly bad internet connection. The regional sysadmin team will have made sure that the XS has all the relevant activities (supplied at install time, or or via a USB stick). Those activities are not in their canonical place... they actually are at http://schoolserver/activities/ So we have 2 options 1 - the activity updater on the client side tries http://schoolserver/activities *first* before trying other urls 2 - it goes directly to the correct url, and we hope that the XS knows all the relevant correct urls (activities have their update url in their metadata) If you count on activities coming from a limited number of sources, maybe the XS can know them all. But if we succeed and there are a million activity authors out there, the 'cheatsheet' approach breaks down. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] How to move on? Spins, SoaS, and more!
Marco Pesenti Gritti wrote: On Sun, Feb 1, 2009 at 7:34 PM, Sebastian Dziallas sebast...@when.com wrote: But regarding the Education Spin: Couldn't we push Sugar in there? The KDE project is doing a great job with their applications regarding education, and they continue to do so. Recently, Greg made me aware of this project [4], where they try to use Plasma for such purposes. Now. Wouldn't it be an idea, to work again on the Education Spin and restructure it a bit, include Sugar, talk about the advantages of using KDE, and so on? I want to ask for your opinion to make sure that this isn't happening too early. But that way, we could provide a great educational solution, based on Fedora, helping both the Sugar and KDE Edu project. But for this, we need a kind of collaboration, between those projects (e.g. Fedora / Sugar or Fedora / KDE Edu), so that we can provide a well designed, usable solution. Can you elaborate on what kind of collaboration are you thinking about here? Is the idea to ship Sugar as an alternative desktop on the Edu spin or something different? Marco Heh. ;) Nothing's written in stone... What I was thinking of was a kind of integration of Sugar into such a spin. Putting as many desktop environments as one can find is probably not the best idea right? So it would need to be worked out, how this (Sugar e.g. KDE Edu) can be combined into a well fitting solution. As I mentioned, the Education Spin is currently based on XFCE. Now think about cscott's work here [1]. What, if we managed to get this into Fedora? And what, if we continued to ship XFCE among with kdeedu, but also included Sugar, with a more or less easy possibility to directly switch between them? Caroline stated that A 4 year old should not face a dialog box asking gnome or sugar. A 12 year old with experience should be able to break out of sugar to the full power of Linux. So. Does this sound like an idea? There might be probably other ways of integrating Sugar here, but it's at least a beginning. --Sebastian [1] http://wiki.laptop.org/go/XFCE_and_Sugar ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Service announcement scheme - (Re: A small request.)
On Mon, Feb 2, 2009 at 14:18, C. Scott Ananian csc...@laptop.org wrote: On Mon, Feb 2, 2009 at 5:13 AM, Bernie Innocenti ber...@laptop.org wrote: Martin Langhoff wrote: On Mon, Feb 2, 2009 at 6:39 PM, C. Scott Ananian csc...@laptop.org wrote: My suggestions: DNS-SD and libepc (http://live.gnome.org/libepc/). There's no need for Sugar-specific solutions here; we just need to use existing standard solutions. Yep - I want existing standard stuff, but the devil we know seems to swamp the spectrum with 802.11s. When I read the Zeroconf book, I got the impression that the _standard_ was carefully designed to minimize needless broadcasts and scale well in real scenarios. I can't comment on the current Avahi _implementation_ though. This is true for wired networks; not necessarily true for mobile and/or wireless networks. Like Martin, you are confusing mDNS with DNS-SD. --scott Also don't blame avahi for the fact that we send out updates every time you alt-tab between shared activities, so that your icon can jump to the appropriate snowflake on everyone else's Neighborhood Views... as well as sending who joined and left... Regards Morgan ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Activity updater
On Mon, Feb 2, 2009 at 13:00, Bernie Innocenti ber...@sugarlabs.org wrote: Jonas Smedegaard wrote: What Debian package? I found no mention of olpc-update anywhere in the source code for Sugar, so I guess you are talking about something OLPC-specific _below_ Sugar, right? olpc-update is the official updater for the core OS of the OLPC distribution. It is very XOOS specific so you probably don't want to package it for Debian. Are you packaging up the sugar-update-control package for Debian? It's here: http://dev.laptop.org/git?p=users/cscott/sugar-update-control;a=summary (I don't know if release tarballs exist for it) My tentative plan, to be further discussed here, is: 1. import the project in gitorious; 2. break the dependency with olpc-update and bitfrost; 3. add it to jhbuild; 4. get the RPM accepted in Fedora; 5a. change the default URL to point at an Activities page on the Sugar Labs wiki. or, 5b. modify addons.sl.o to understand the OLPC microformat. The choice between 5a or 5b depends on the amount of progress we do with remora over the next few weeks. To speed up packaging, we might also integrate the updater in the main sugar package. I'd like to get help for any of these points. Actually, I will follow the mantra of doing only what nobody else is already doing. Your plan sounds good to me, ping me in #sugar when you get stuck in a Sugar weirdness. Thanks, Tomeu ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] Activity updater
Jonas Smedegaard wrote: What Debian package? I found no mention of olpc-update anywhere in the source code for Sugar, so I guess you are talking about something OLPC-specific _below_ Sugar, right? olpc-update is the official updater for the core OS of the OLPC distribution. It is very XOOS specific so you probably don't want to package it for Debian. Are you packaging up the sugar-update-control package for Debian? It's here: http://dev.laptop.org/git?p=users/cscott/sugar-update-control;a=summary (I don't know if release tarballs exist for it) My tentative plan, to be further discussed here, is: 1. import the project in gitorious; 2. break the dependency with olpc-update and bitfrost; 3. add it to jhbuild; 4. get the RPM accepted in Fedora; 5a. change the default URL to point at an Activities page on the Sugar Labs wiki. or, 5b. modify addons.sl.o to understand the OLPC microformat. The choice between 5a or 5b depends on the amount of progress we do with remora over the next few weeks. To speed up packaging, we might also integrate the updater in the main sugar package. I'd like to get help for any of these points. Actually, I will follow the mantra of doing only what nobody else is already doing. -- // Bernie Innocenti - http://www.codewiz.org/ \X/ Sugar Labs - http://www.sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] A small request.
On Mon, Feb 2, 2009 at 1:06 AM, Martin Langhoff martin.langh...@gmail.com wrote: On Mon, Feb 2, 2009 at 6:38 PM, C. Scott Ananian csc...@laptop.org wrote: I still believe the proper way to do this is to have a local offline cache. The protocol was explicitly designed to be easily cacheable. Because the use case looks like this: 1 - the XS has no way to know what activities are on the XO The XS has no way to know what web pages are in the world. 2 - an activity on the XO can name a URL in its metadata that the XS does _not_ know about A user may type a URL into a browser bar that the XS does not know about. 3 - the XS cannot intercept that request unless we develop mind-reading interfaces Proxy caches do just fine without psitronic technology. I don't understand your problem. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] What is a blocker bug today?
Marco Pesenti Gritti wrote: I guess at some point the default was Blocker, because there lots of tickets marked that way in trac. Yeah, we should re-prioritize them. Do we have a Bugmaster role? We should /me steps back... quickly! -- // Bernie Innocenti - http://www.codewiz.org/ \X/ Sugar Labs - http://www.sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] What is a blocker bug today?
A bugsquad even! Reprioritized most of mine yesterday... Marco On Mon, Feb 2, 2009 at 2:47 PM, Bernie Innocenti ber...@codewiz.org wrote: Marco Pesenti Gritti wrote: I guess at some point the default was Blocker, because there lots of tickets marked that way in trac. Yeah, we should re-prioritize them. Do we have a Bugmaster role? We should /me steps back... quickly! -- // Bernie Innocenti - http://www.codewiz.org/ \X/ Sugar Labs - http://www.sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] sugar-widgets request
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 On Mon, Feb 02, 2009 at 11:08:11AM +0100, Tomeu Vizoso wrote: On Mon, Feb 2, 2009 at 02:32, Aleksey Lim alsr...@member.fsf.org wrote: Hi all, While tweaking/hacking some activities I have to, from time to time, copypaste code between activities. Sometime it works well: tempo slider from TamTam activities means 20-30 lines and 5-7 images. Now (for Speak activity) I need ChatBox widget from Chat and it costs 400 lines. Its a good idea to support those 400 lines in one repo. Whats the right place for it? And in common, should we collect such widgets/libraries in one place, sugar-toolkit? new project sugar-widgets? A new project seems like more work for both upstream developers and packagers. Any downsides if we put them in sugar-toolkit? A benefit of using a separate package could be (depending on which features from recent versions of core packages that it rely on) that it could work even with existing deployments using Sugar 0.82! - Jonas - -- * Jonas Smedegaard - idealist og Internet-arkitekt * Tlf.: +45 40843136 Website: http://dr.jones.dk/ [x] quote me freely [ ] ask before reusing [ ] keep private -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.9 (GNU/Linux) iEYEARECAAYFAkmG3ecACgkQn7DbMsAkQLhcOQCgozsNqouy9n84d86P92BRqZSl dkMAnRyWHN9TLnd4sqWStk0f8OJ3glmu =3NMh -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Is it possible to disable sharing for an Activity?
I think this project often makes the perfect into the enemy of the good. Consequently we end up having less collaboration than, e.g., any system in the last 10 years that could install vnc server, while claiming that collaboration is a principal focus of the project. On Mon, Feb 2, 2009 at 3:34 PM, Wade Brainerd wad...@gmail.com wrote: I think some simplistic automatic collaboration being built into Sugar, has been discussed, possibly even prototyped. Just a matter of engineering motivation/time perhaps. -Wade On Mon, Feb 2, 2009 at 6:30 PM, Carol Farlow Lerche c...@msbit.comwrote: I'm guessing someone has already suggested this on some list or other, but in my experience kids like to watch over each other's shoulder, and a default collaboration of everyone watches, one person types vnc would in my opinion be the 80 of a collaboration 80-20 rule. I think this ought to be implemented in the sugar infrastructure, and then let activities that have an obvious extended collaboration (such as two person games or shared authorship documents) do something more. 2009/2/2 Wade Brainerd wad...@gmail.com There might be something in the Sugar Almanac, see http://sugarlabs.org/go/ActivityTeam/Resources for a link. Alternately, an example of how to disable sharing is here: http://git.sugarlabs.org/projects/math/repos/mainline/blobs/master/mathactivity.py#line75 Note to Sugar toolkit guys, I'd love to have a formal API to indicate collaboration not supported. Best, Wade On Mon, Feb 2, 2009 at 6:10 PM, James Simmons jim.simm...@walgreens.com wrote: First, I want to praise whoever put together the Sugar packages for Fedora 10. After struggling with Xubuntu and with sugar-jhbuild on openSUSE I finally have a sugar test environment where everything seems to work! It was well worth wiping out my openSUSE install and starting over with a new distribution. I'll probably do the same to my Xubuntu box eventually. Second, now that I have this I want to perfect collaboration on my two Activities, Read Etexts and View Slides. Unfortunately, I am convinced that collaboration in View Slides that involves sending large Zip archives over the network is not and never will be practical. What I'm thinking about now is making the person sharing a slide show see only the image being viewed on the XO that has the full presentation. The master XO would page through the slides and those sharing would follow along. I'm not sure that's practical, either. While I'm figuring this out, what I'd really like to do is release a version of View Slides that has no collaboration at all. This would mean hiding the control on the Activity toolbar that supports collaboration. When I figure out something intelligent to do with collaboration I'll restore it. Is this possible, and how would I go about doing it? Thanks, James Simmons ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Don't think for a minute that power concedes. We have to work like our future depends on it. -- Barack Obama -- Don't think for a minute that power concedes. We have to work like our future depends on it. -- Barack Obama ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Service announcement scheme - (Re: A small request.)
Martin Langhoff wrote: On Mon, Feb 2, 2009 at 6:39 PM, C. Scott Ananian csc...@laptop.org wrote: My suggestions: DNS-SD and libepc (http://live.gnome.org/libepc/). There's no need for Sugar-specific solutions here; we just need to use existing standard solutions. Yep - I want existing standard stuff, but the devil we know seems to swamp the spectrum with 802.11s. When I read the Zeroconf book, I got the impression that the _standard_ was carefully designed to minimize needless broadcasts and scale well in real scenarios. I can't comment on the current Avahi _implementation_ though. Even if the standard itself is flawed, designing a custom protocol to do the same thing is going to be a lot of work and probably end up facing the very same design issues that made the IEFT's standard inadequate for us in the first place. When it comes to non-trivial networking protocols, I don't trust any given individual to be able to do a good job without going through an *extensive* iterative design process with public reviews of interim drafts. What's hardest about networking is that it looks deceptively easy at first :-) -- // Bernie Innocenti - http://www.codewiz.org/ \X/ Sugar Labs - http://www.sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Is it possible to disable sharing for an Activity?
I think that the addition of a new property in the activity.info file would be logical here. Make it an integer indicating the maximum number of supported participants. Unshared activities would report '1', activities like video chat (with technical limitations) or chess (with obvious player limits) might specify 2, and others could specify another cap based on resource requirements and/or a constant to indicate an unbounded number. That number could be used both to show/hide the sharing controls (in the activity or elsewhere) for that activity, and also help keep the participants list at a manageable size for the given activity. Limitations are natural, and activity specific; it's not reasonable to expect all collaborative activities to scale in the same way. Scott (CC'd) has already come up with some really nice proposals for adding VNC as an alternate colaboration mechanism for all activities. In my mind, this would work perfectly with the above scheme, whereby any activity that already has max_participants in it could be viewed in that manner. Scott, could you point to any materials you've already written up on the matter? Would you have time and/or desire to assist others who are interested in taking on such a feature? I'd love to see this happen, myself, and have given some preliminary thought to the UI already. - Eben 2009/2/2 Carol Farlow Lerche c...@msbit.com: I'm guessing someone has already suggested this on some list or other, but in my experience kids like to watch over each other's shoulder, and a default collaboration of everyone watches, one person types vnc would in my opinion be the 80 of a collaboration 80-20 rule. I think this ought to be implemented in the sugar infrastructure, and then let activities that have an obvious extended collaboration (such as two person games or shared authorship documents) do something more. 2009/2/2 Wade Brainerd wad...@gmail.com There might be something in the Sugar Almanac, see http://sugarlabs.org/go/ActivityTeam/Resources for a link. Alternately, an example of how to disable sharing is here: http://git.sugarlabs.org/projects/math/repos/mainline/blobs/master/mathactivity.py#line75 Note to Sugar toolkit guys, I'd love to have a formal API to indicate collaboration not supported. Best, Wade On Mon, Feb 2, 2009 at 6:10 PM, James Simmons jim.simm...@walgreens.com wrote: First, I want to praise whoever put together the Sugar packages for Fedora 10. After struggling with Xubuntu and with sugar-jhbuild on openSUSE I finally have a sugar test environment where everything seems to work! It was well worth wiping out my openSUSE install and starting over with a new distribution. I'll probably do the same to my Xubuntu box eventually. Second, now that I have this I want to perfect collaboration on my two Activities, Read Etexts and View Slides. Unfortunately, I am convinced that collaboration in View Slides that involves sending large Zip archives over the network is not and never will be practical. What I'm thinking about now is making the person sharing a slide show see only the image being viewed on the XO that has the full presentation. The master XO would page through the slides and those sharing would follow along. I'm not sure that's practical, either. While I'm figuring this out, what I'd really like to do is release a version of View Slides that has no collaboration at all. This would mean hiding the control on the Activity toolbar that supports collaboration. When I figure out something intelligent to do with collaboration I'll restore it. Is this possible, and how would I go about doing it? Thanks, James Simmons ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel -- Don't think for a minute that power concedes. We have to work like our future depends on it. -- Barack Obama ___ Devel mailing list de...@lists.laptop.org http://lists.laptop.org/listinfo/devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Service announcement scheme - (Re: A small request.)
C. Scott Ananian wrote: When I read the Zeroconf book, I got the impression that the _standard_ was carefully designed to minimize needless broadcasts and scale well in real scenarios. I can't comment on the current Avahi _implementation_ though. This is true for wired networks; not necessarily true for mobile and/or wireless networks. IEEE chose to make wi-fi networks look like 802.11 LANs, similar to ethernet. It might have been a bad idea in retrospect, but now we have to live with it. AFAIK, the bulk of the problem with multicasts over 802.11s (and not all wi-fi networks) is that those must be propagated at the slowest possible link speed in order to reach all nodes. Like Martin, you are confusing mDNS with DNS-SD. Ok, but how would the laptops advertise their SRV records without multicast DNS? Wait, are you perhaps suggesting to use DDNS to publish those services on a nameserver running on the XS? -- // Bernie Innocenti - http://www.codewiz.org/ \X/ Sugar Labs - http://www.sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Is it possible to disable sharing for an Activity?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eben Eliason wrote: I think that the addition of a new property in the activity.info file would be logical here. Make it an integer indicating the maximum number of supported participants. OK, but as an Activity author I might like to specify that cap at runtime, depending on many things, such as the size of the document. I might even want to let the initiator choose the number of participants. I think we should also have a runtime API, so that the cap that can be varied at any time. In fact, it might be nice to have a a generic solution for defining config variables that can be controlled either statically or at runtime. We have mentioned a wide variety of such variables, including things like whether screen rotation is supported. Scott (CC'd) has already come up with some really nice proposals for adding VNC as an alternate colaboration mechanism for all activities. In my mind, this would work perfectly with the above scheme, whereby any activity that already has max_participants in it could be viewed in that manner. I don't see why any Activity should be excluded from such VNC sharing, regardless of max_participants. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmHkNIACgkQUJT6e6HFtqQBlQCdF4AhUy+NWkwYqVR/qMyl/m2H UpAAniXtXxWRQuM8o8iqtiyJ0uB4o05Z =BI5d -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Is it possible to disable sharing for an Activity?
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eben Eliason wrote: On Mon, Feb 2, 2009 at 7:33 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: In my mind, this would work perfectly with the above scheme, whereby any activity that already has max_participants in it could be viewed in that manner. I don't see why any Activity should be excluded from such VNC sharing, regardless of max_participants. Of course not. I didn't mean to imply such a limitation; only that the VNC solution would be the /only/ option after some participants limit was reached. That is, you could either Join or Watch any shared activity, but the Join option would disappear once full...Watch would remain. It's possible we'd have an upper bound on the number of people who could watch as well, but I don't think that's an activity-specific parameter. Oh! That's beautiful. Let's do that. - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmHl60ACgkQUJT6e6HFtqTXXACdH1WGy6vrO8JibUPy+AbPXQs0 5X0An1Y3zcLXrr3kP9itQ8pUHZ7ujjpD =YKXn -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Service announcement scheme - (Re: A small request.)
Morgan Collett wrote: Also don't blame avahi for the fact that we send out updates every time you alt-tab between shared activities, so that your icon can jump to the appropriate snowflake on everyone else's Neighborhood Views... as well as sending who joined and left... Mature GUIs have a common pattern to avoid too much graphical flickering on possibly rapid state transitions, such as setting a busy pointer or disabling buttons while some operation is in progress. I don't know if it has a name, but the algorithm is exactly the same for de-bouncing mechanical keys: you propagate the event only after the state has settled for a certain amount of time. This would take away a certain percentage of spurious updates, but the number basically remains proportional to the number of users so it doesn't scale much better. -- // Bernie Innocenti - http://www.codewiz.org/ \X/ Sugar Labs - http://www.sugarlabs.org/ ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Is it possible to disable sharing for an Activity?
On 3 Feb 2009, at 01:02, Benjamin M. Schwartz wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Eben Eliason wrote: On Mon, Feb 2, 2009 at 7:33 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: In my mind, this would work perfectly with the above scheme, whereby any activity that already has max_participants in it could be viewed in that manner. I don't see why any Activity should be excluded from such VNC sharing, regardless of max_participants. Of course not. I didn't mean to imply such a limitation; only that the VNC solution would be the /only/ option after some participants limit was reached. That is, you could either Join or Watch any shared activity, but the Join option would disappear once full...Watch would remain. It's possible we'd have an upper bound on the number of people who could watch as well, but I don't think that's an activity-specific parameter. Oh! That's beautiful. Let's do that. I don't mean to rain on the parade here, but am I the only one who finds VNC slow even on high spec equipment over a dedicated broadband connection? I do use it occasionally for remote support, so it does have its uses – but a handful of XOs in the same wireless spectrum? Ouch. From a technical stand point VNC is going to be almost always more memory hungry, more cpu hungry, and more bandwidth hungry than most activity collaborations, seems to be an overly hopeful collaboration method to fallback on. Happy to be proven wrong, and I guess it could be a Sugar feature not really intended for XOs. Regards, --Gary - --Ben -BEGIN PGP SIGNATURE- Version: GnuPG v2.0.9 (GNU/Linux) iEYEARECAAYFAkmHl60ACgkQUJT6e6HFtqTXXACdH1WGy6vrO8JibUPy+AbPXQs0 5X0An1Y3zcLXrr3kP9itQ8pUHZ7ujjpD =YKXn -END PGP SIGNATURE- ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] A small request.
On Tue, Feb 3, 2009 at 3:28 PM, Benjamin M. Schwartz bmsch...@fas.harvard.edu wrote: How does the XS know what URLs to mask? Surely the URLs to mask are the source URLs of the .xo bundles in Hi Ben, The gotcha is described in the paragraph you snipped :-) right after my question. I try hard to avoid asking very stupid questions, so if one of my questions sounds _really_ profoundly idiotic, it might warrant a re-read :-) We have no time for shallow discussion. m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Service announcement scheme - (Re: A small request.)
On Tue, Feb 3, 2009 at 11:13 AM, C. Scott Ananian csc...@laptop.org wrote: 802.11s is not simple, nor safe. lol. That's right. Now, you are talking about DNS-SD without mDNS. Spent some good time reading up on both, and DNS-SD sounds good for what we're trying to do. Everybody uses them together, however, and all the nice libraries (avahi and friends) make no distinction between the two. Maybe I'm looking at the wrong docs - so pointers welcome. If I'm right, however, we can still write our own simple dns-sd client glue and a abuse named on the XS. Please concentrate on plain 802.11 networks for now. It's not so black-and-white . Whatever its status right now, 802.11s is still an important consideration. cheers, m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] Is it possible to disable sharing for an Activity?
On Mon, Feb 2, 2009 at 9:26 PM, Gary C Martin g...@garycmartin.com wrote: Happy to be proven wrong, and I guess it could be a Sugar feature not really intended for XOs. Let's let the flowers bloom: I don't doubt that there are many ways to make *better* collaboration, on an activity-by-activity basis. But VNC is something that can be created as a common baseline. Let's start by doing that, and improve it on a case-by-case basis, instead of having *no collaboration* as our baseline. FWIW, I second Carol's comments: VNC works quite nicely on fast local networks, such as direction connections between XOs, and I've used it on clients as simple as a Palm Pilot and a Mac SE/30. Reducing graphic busy-ness and palette size helps a lot! Also: don't run xvncviewer remotely: VNC is network efficient, but the way its X client uses the network between it and the X server is definitely *not*! --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] A small request.
On Tue, Feb 3, 2009 at 3:46 PM, C. Scott Ananian csc...@laptop.org wrote: Only works with HTTP -- that's why were are careful to make our protocols only use HTTP. Several of our protocols are http based, but not all. What I am stating is that for almost all protocols we need a service announcement scheme to do smart things locally. For HTTP, in _some_ cases, we can pull tricks, but that's not a sustainable approach. It's not a cheat sheet: it's a list of cached content. If your activities are coming from lots of different sources, then your update URLs will be different. What's wrong with that? In some cases we cannot guess the URLs, as I described a couple of emails ago. m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] A small request.
On Mon, Feb 2, 2009 at 10:53 PM, Martin Langhoff martin.langh...@gmail.com wrote: On Tue, Feb 3, 2009 at 3:46 PM, C. Scott Ananian csc...@laptop.org wrote: Only works with HTTP -- that's why were are careful to make our protocols only use HTTP. Several of our protocols are http based, but not all. Please be specific. What I am stating is that for almost all protocols we need a service announcement scheme to do smart things locally. For HTTP, in _some_ cases, we can pull tricks, but that's not a sustainable approach. It's hard to argue with this unless you actually provide examples. It's not a cheat sheet: it's a list of cached content. If your activities are coming from lots of different sources, then your update URLs will be different. What's wrong with that? In some cases we cannot guess the URLs, as I described a couple of emails ago. You failed to convince me. How can a school provide activities without knowing their update URLs? How is that hard to do? I certainly don't have to tell my existing wwwoffle cache that (for example) what pages I read daily. --scott -- ( http://cscott.net/ ) ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] A small request.
On Tue, Feb 3, 2009 at 5:10 PM, C. Scott Ananian csc...@laptop.org wrote: You failed to convince me. How (...)? All I can suggest is that you go back on this thread and read my email. Here's a clarification (I know my writing isn't always clear): the url in the metadata is not expected to remain static over time. m -- martin.langh...@gmail.com mar...@laptop.org -- School Server Architect - ask interesting questions - don't get distracted with shiny stuff - working code first - http://wiki.laptop.org/go/User:Martinlanghoff ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
