Re: [Sugar-devel] updating from aslo
On Fri, Jul 17, 2009 at 19:39, Daniel Drake wrote: > 2009/7/16 David Farning : >> A possible answer would be to abstract ALSOParse.py and microformat.py >> as back ends for Sugar-Update-Control (SUC). > > It's not so much the issue of losing support for the existing > widely-deployed setup (although that would be unfortunate), it's that > this seems to lack design. The microformat-style update (along with > certain characteristics of the updater and server implementation) is > not perfect, but it is good for field use and "G1G1" style internet > users. > > The motivation for moving to "aslo" seems to be only that of "because > it's running on sugarlabs.org," without consideration for any > technical pros or cons of the different format, how it might be > deployed in the field, etc. I think you should take a more detailed > approach to this, without limiting yourself to the quirks and current > behaviour of the aslo code. I guess I'm confused, are you saying that activity authors and users don't gain anything by using ASLO instead of the previous wiki system? Then why did we spent so much time fitting ASLO to our needs? It's not like ASLO has been always running in sugarlabs.org, lots of effort from several people from several teams in SLs has gone to make it possible, it's not the wet dream of a single coder. If I misunderstood you and you weren't questioning the usefulness of ASLO itself, then I don't see why it doesn't make sense to get the update data from where it already is. Regards, Tomeu > Daniel > ___ > 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] updating from aslo
On Fri, Jul 17, 2009 at 1:39 PM, Daniel Drake wrote: > 2009/7/16 David Farning : > > A possible answer would be to abstract ALSOParse.py and microformat.py > > as back ends for Sugar-Update-Control (SUC). > > It's not so much the issue of losing support for the existing > widely-deployed setup (although that would be unfortunate), it's that > this seems to lack design. The microformat-style update (along with > certain characteristics of the updater and server implementation) is > not perfect, but it is good for field use and "G1G1" style internet > users. > > The motivation for moving to "aslo" seems to be only that of "because > it's running on sugarlabs.org," without consideration for any > technical pros or cons of the different format, how it might be > deployed in the field, etc. I think you should take a more detailed > approach to this, without limiting yourself to the quirks and current > behaviour of the aslo code. +1 Do we have use cases for this? It seems like this is sorta like a bunch of other thngs we need to enable. Off the top of my head - Teacher shares a file with a class - Teacher shares a file or lesson plan or student work sample with other teachers - Student shares with classmate for peer review - Student shares with teacher for assessment (need an easy way for teachers to see all students work) - Student shares with outside world - Student shares with school community - Teacher or student gets an activity for Sugar - Teacher or Student learns what is possible with Sugar from examples - Students or classes of students collaobrate to co-create projects All different, but it would be good if the end users felt there was some consistant logic to how they did these tasks which may well be related in their minds. > > > Daniel > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > -- Caroline Meeks Solution Grove carol...@solutiongrove.com 617-500-3488 - Office 505-213-3268 - Fax ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] updating from aslo
2009/7/16 David Farning : > A possible answer would be to abstract ALSOParse.py and microformat.py > as back ends for Sugar-Update-Control (SUC). It's not so much the issue of losing support for the existing widely-deployed setup (although that would be unfortunate), it's that this seems to lack design. The microformat-style update (along with certain characteristics of the updater and server implementation) is not perfect, but it is good for field use and "G1G1" style internet users. The motivation for moving to "aslo" seems to be only that of "because it's running on sugarlabs.org," without consideration for any technical pros or cons of the different format, how it might be deployed in the field, etc. I think you should take a more detailed approach to this, without limiting yourself to the quirks and current behaviour of the aslo code. Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] updating from aslo
On Fri, Jul 17, 2009 at 07:29, David Farning wrote: > Going forward, this option represents a increase in usability with a > very low cost of maintenance. > Sure, but what about legacy deployments, where it is rare to update the existing software? -- Luke Faraone http://luke.faraone.cc ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] updating from aslo
On Fri, Jul 17, 2009 at 12:01 AM, Michael Stone wrote: > David, > > Could you please point me to an explanation of why it's hard to get ASLO to > generate the microformat that is already understood by the tens of thousands > of > sugar-0.82 machines in Uruguay, the US, and elsewhere so that I can form a > more > solid opinion of your work? I don't know if it is hard to get ASLO to generate microformat. The reasons for going with the xml are: -client side It only take one line of python to construct the query URL. It only takes 4 lines of python to parse the resulting xml -server side The xml based update date mechanism is already part of upstream AMO Going forward, this option represents a increase in usability with a very low cost of maintenance. david > Thanks, > > Michael > ___ > Sugar-devel mailing list > Sugar-devel@lists.sugarlabs.org > http://lists.sugarlabs.org/listinfo/sugar-devel > -- David Farning Sugar Labs www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] updating from aslo
David, Could you please point me to an explanation of why it's hard to get ASLO to generate the microformat that is already understood by the tens of thousands of sugar-0.82 machines in Uruguay, the US, and elsewhere so that I can form a more solid opinion of your work? Thanks, Michael ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] updating from aslo
On Thu, Jul 16, 2009 at 18:23, David Farning wrote: > On Thu, Jul 16, 2009 at 10:09 AM, Daniel Drake wrote: >> On Wed, 2009-07-15 at 10:17 -0500, David Farning wrote: >>> Attached is a very early prototype of a sugar updater which pulls from ASLO. >>> >>> It kind-of works on jhbuild;-/ To test, unzip and drop it into >>> sugar-jhbuild/install/share/sugar/extensions/cpsection. >>> >>> run using 'install/share/sugar/extensions/cpsection/updater/model.py' >>> >>> Big Issues: >>> The GUI interface is reporting a network error. >> >> I personally feel that this kind of approach is not a great idea, but I >> suppose it depends who your target users are. > > A possible answer would be to abstract ALSOParse.py and microformat.py > as back ends for Sugar-Update-Control (SUC). > > SUC could either fall back from ASLO to microformat or be configured > to connect to either ASLO or microformat by default. Would be possible to autodetect the format that the server understands? > A third alternative would be to add a local-server backend. It would > be pretty straight forward to write a script to poll ASLO for > available updates, create a text file of available update, and > download the updates to a directory. This data could then be moved to > individual deployments as needed. > > SUC could then update individual machines from a local server using > data created above. > > I'll start working on abstracting out the backends today. Great, I hope to find time tomorrow to give it a first look. Regards, Tomeu > david > >> This type of setup seems inappropriate for low-bandwidth/high-latency >> OLPC-style deployments, since it seems to rely on the internet. Unless >> you're suggesting that people run the updates website on the school >> server, in which case xs-activity-server would need to be reworked into >> that, or an alternative solution developed which does not require >> deployers doing too much setup. >> >> The current updater has some nice properties in that the microformat is >> simple, the surrounding infrastructure is in place for deployments (use >> xs-activity-server, or maintain a .html file), and that at least with >> this patch it will operate very well even without internet access: >> http://dev.laptop.org/ticket/9259 >> >> Daniel >> >> >> > > > > -- > David Farning > Sugar Labs > 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] updating from aslo
On Thu, Jul 16, 2009 at 10:09 AM, Daniel Drake wrote: > On Wed, 2009-07-15 at 10:17 -0500, David Farning wrote: >> Attached is a very early prototype of a sugar updater which pulls from ASLO. >> >> It kind-of works on jhbuild;-/ To test, unzip and drop it into >> sugar-jhbuild/install/share/sugar/extensions/cpsection. >> >> run using 'install/share/sugar/extensions/cpsection/updater/model.py' >> >> Big Issues: >> The GUI interface is reporting a network error. > > I personally feel that this kind of approach is not a great idea, but I > suppose it depends who your target users are. A possible answer would be to abstract ALSOParse.py and microformat.py as back ends for Sugar-Update-Control (SUC). SUC could either fall back from ASLO to microformat or be configured to connect to either ASLO or microformat by default. A third alternative would be to add a local-server backend. It would be pretty straight forward to write a script to poll ASLO for available updates, create a text file of available update, and download the updates to a directory. This data could then be moved to individual deployments as needed. SUC could then update individual machines from a local server using data created above. I'll start working on abstracting out the backends today. david > This type of setup seems inappropriate for low-bandwidth/high-latency > OLPC-style deployments, since it seems to rely on the internet. Unless > you're suggesting that people run the updates website on the school > server, in which case xs-activity-server would need to be reworked into > that, or an alternative solution developed which does not require > deployers doing too much setup. > > The current updater has some nice properties in that the microformat is > simple, the surrounding infrastructure is in place for deployments (use > xs-activity-server, or maintain a .html file), and that at least with > this patch it will operate very well even without internet access: > http://dev.laptop.org/ticket/9259 > > Daniel > > > -- David Farning Sugar Labs www.sugarlabs.org ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] updating from aslo
On Wed, 2009-07-15 at 10:17 -0500, David Farning wrote: > Attached is a very early prototype of a sugar updater which pulls from ASLO. > > It kind-of works on jhbuild;-/ To test, unzip and drop it into > sugar-jhbuild/install/share/sugar/extensions/cpsection. > > run using 'install/share/sugar/extensions/cpsection/updater/model.py' > > Big Issues: > The GUI interface is reporting a network error. I personally feel that this kind of approach is not a great idea, but I suppose it depends who your target users are. This type of setup seems inappropriate for low-bandwidth/high-latency OLPC-style deployments, since it seems to rely on the internet. Unless you're suggesting that people run the updates website on the school server, in which case xs-activity-server would need to be reworked into that, or an alternative solution developed which does not require deployers doing too much setup. The current updater has some nice properties in that the microformat is simple, the surrounding infrastructure is in place for deployments (use xs-activity-server, or maintain a .html file), and that at least with this patch it will operate very well even without internet access: http://dev.laptop.org/ticket/9259 Daniel ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] updating from ASLO
On Thu, Jun 18, 2009 at 08:31:42PM +, Aleksey Lim wrote:
> On Thu, Jun 18, 2009 at 02:28:35PM -0500, David Farning wrote:
> I tried this:
> http://activities-devel.sugarlabs.org/services/update.php?id=bounce&appID={3ca105e0-2280-4897-99a0-c277d1b733d2}&version=foo
>
> id: GUID of activity
in our case its a bundle_id
--
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
Re: [Sugar-devel] updating from ASLO
On Thu, Jun 18, 2009 at 02:28:35PM -0500, David Farning wrote:
> The basic principle behind the ALSO updater seems to be that you send
> a url to ASLO - Services and it responds with a list of available
> updates.
>
> Server side, the updater is part of ALSO services, a collection of
> activity related services. The relevant code is found under
> site/app/webroot/services .
>
> The location of services is defined in config.php. I think that we
> defined it as http://activities.sugarlabs.org/services .
>
> The url is sent by the client is of the form
>
> * service URL schema version
> * app name
> * app version
> * app buildid
> * app buildtarget
> * app locale
> * aus channel
> * distribution name
> * distribution version
>
> e.g.,
>
> /update/3/Firefox/3.0a8pre/2007083015/Darwin_x86-gcc3/en-US/default/Darwin%208.10.1/testpartner/1.0/update.xml
>
> see https://wiki.mozilla.org/Software_Update for more information.
>
> Client side Firefox generates the url via the following java script code.
>
> http://mxr.mozilla.org/firefox/source/toolkit/mozapps/update/src/nsUpdateService.js.in
>
> It should be straight forward to modify
> sugar-jhbuild/source/sugar-update-control/src to create a appropriate
> url.
>
> Currently I am stuck trying to manually create a test url. I think
> the following should work
>
> https://aus2.mozilla.org/update/3/Firefox/3.0a8pre/2007083015/Darwin_x86-gcc3/en-US/default/Darwin%208.10.1/testpartner/1.0/update.xml
>
> but it just returns
>
>
>
>
>
> Anyone see anything obvious that I am screwing up?
>
> thanks
> david
>
I tried this:
http://activities-devel.sugarlabs.org/services/update.php?id=bounce&appID={3ca105e0-2280-4897-99a0-c277d1b733d2}&version=foo
id: GUID of activity
appID: {3ca105e0-2280-4897-99a0-c277d1b733d2} magic string for sugar app
version: version id(make sense only for non-public activities)
additional "&debug=true" outputs logs
--
Aleksey
___
Sugar-devel mailing list
Sugar-devel@lists.sugarlabs.org
http://lists.sugarlabs.org/listinfo/sugar-devel
[Sugar-devel] updating from ASLO
The basic principle behind the ALSO updater seems to be that you send a url to ASLO - Services and it responds with a list of available updates. Server side, the updater is part of ALSO services, a collection of activity related services. The relevant code is found under site/app/webroot/services . The location of services is defined in config.php. I think that we defined it as http://activities.sugarlabs.org/services . The url is sent by the client is of the form * service URL schema version * app name * app version * app buildid * app buildtarget * app locale * aus channel * distribution name * distribution version e.g., /update/3/Firefox/3.0a8pre/2007083015/Darwin_x86-gcc3/en-US/default/Darwin%208.10.1/testpartner/1.0/update.xml see https://wiki.mozilla.org/Software_Update for more information. Client side Firefox generates the url via the following java script code. http://mxr.mozilla.org/firefox/source/toolkit/mozapps/update/src/nsUpdateService.js.in It should be straight forward to modify sugar-jhbuild/source/sugar-update-control/src to create a appropriate url. Currently I am stuck trying to manually create a test url. I think the following should work https://aus2.mozilla.org/update/3/Firefox/3.0a8pre/2007083015/Darwin_x86-gcc3/en-US/default/Darwin%208.10.1/testpartner/1.0/update.xml but it just returns Anyone see anything obvious that I am screwing up? thanks david ___ Sugar-devel mailing list Sugar-devel@lists.sugarlabs.org http://lists.sugarlabs.org/listinfo/sugar-devel
