[Sugar-devel] [DESIGN] optional automatic updates

[Jerry Vonau]

> On August 7, 2014 at 10:17 PM Martin Abente
> <martin.abente.lahaye at gmail.com> wrote:
>
>
> On Thu, Aug 7, 2014 at 10:17 PM, Jerry Vonau <me at jvonau.ca> wrote:
>
> >
> >
> > > On August 7, 2014 at 8:33 PM Martin Abente
> > > <martin.abente.lahaye at gmail.com> wrote:
> > >
> > >
> > > On Thu, Aug 7, 2014 at 8:26 PM, Jerry Vonau <me at jvonau.ca> wrote:
> > >
> > > > Hi,
> > > >
> > > > > On August 5, 2014 at 7:34 PM Martin Abente
> > > > > <martin.abente.lahaye at gmail.com> wrote:
> > > > >
> > > > >
> > > > > Hello everyone,
> > > > >
> > > > > A few development cycles ago, dsd added a useful new feature:
> > > > > automatic
> > > > > activities updates.
> > > >
> > > > Um, sugar 0.100 was not that long ago, kind of liked the way the
> > > > old
> > > > sugar-update-control worked, all that was really missing was the
> > > > auto-updating. For the record there never was a sugar-control-panel
> > > > command
> > > > line for the updater, that was the only piece missing.

I take that back, there was the ability[1] to run the old updater from the
cli, but that stopped working at some point.

> > > > When I was involved
> > > > with AU we went further, extending the updater to just select
> > > > activities
> > > > that were already installed, leaving the ones not installed
> > > > unchecked
> > > > by
> > > > default. This presented a list of optional activities that MAYBE
> > > > installed,
> > > > ones that are updates would be pre-selected, one just needed start
> > > > the
> > > > install[1].
> > > >
> > > > > This has been of great help in deployments such as in
> > > > > Australia. However, because the current implementation will
> > > > > always
> > > > > update
> > > > > or install activities (when working in automatic mode), some
> > > > > deployments
> > > > > might be unable to use this feature. A real case scenario is when
> > > > > some of
> > > > > the activities are too big for massive activities updates.
> > > > >
> > > >
> > > > Think one option that is needed is to skip installing new
> > > > activities
> > > > that
> > > > are not already installed.
> > >
> > >
> > > Installing new activities could be needed too. Both cases are valid
> > > though,
> > > and is ultimately a deployment's decision. This feature can help with
> > > both
> > > for new install AND updates.
> > >
> >
> > In this scheme how does one prevent the re-installation of a removed
> > unwanted activity?
> >
>
> As things are now (in sugar master) the updater will simply install (or
> upgrade) everything in the list. This feature tries to improve the
> current
> scheme from the deployment POV.
>
> If someone can come up with a decent solution to handle this from the
> end-user POV, that would also be a nice improvement.
>
>
> >
> > > The whole point is to give deployment the flexibility, so we
> > > (developers)
> > > don't make the decision for them (deployments) for what should or
> > > should
> > > not update.
> > >
> >
> > How do you do that when the microformat page is not under the control
> > of
> > the end-users with no way of changing the url in UI except altering the
> > entries in dconf?
> >

The ability to alter the updater url from within the UI might be a welcome
addition, then you could create a webpage that defines the activities for a
classroom.

> > >
> > > > The use case is "the in the field teacher" does
> > > > not want a certain activity present for what ever reason on the XOs
> > > > in
> > > > their classroom and has removed the activity.
> > > >
> > > > > Therefore, I propose to extend microformat updater with an extra
> > > > > field to
> > > > > mark activities as optional, so these optional activities won't
> > > > > be
> > > > > installed or upgraded automatically. This flexibility will allow
> > > > > deployments to use automatic updates and user will benefit from
> > > > > automatic
> > > > > updates.
> > > > >
> > > >
> > > > Think this is not really needed, more careful planning by the
> > > > deployment is
> > > > really what is needed here.
> > >
> > >
> > >
> > >
> > > > > I have created a feature page [1] with more details and a initial
> > > > > implementation [2] of the feature itself (because is easier for
> > > > > me to
> > > > > talk
> > > > > with working code).
> > > > >
> > > >
> > > > Would ALSO benefit with the same treatment? Think that is where
> > > > this
> > > > could
> > > > be really be useful, stopping a potentially large download from
> > > > starting.
> > > >
> > > >
> > > You mean supporting this in ASLO?
> > >
> > >
> >
> > Yes, so SoaS/Sugar Desktop doesn't start a large unexpected download,
> > we
> > are talking about bandwidth usage right?
> >
>
> Bandwidth is just one example, there are other scenarios like a
> deployment
> that simply wants to provide extra activities through the updater, but
> without forcing clients to install it.
>
> It is important to notice the difference between ASLO and microformat
> back-ends; deployments can control microformat back-ends, is just a text
> file after all. To support this in ASLO, we need to change ALSO too. So
> is
> not something we can just change in Sugar.
>
>
> >
> >
> > > > > Let me know what you guys think!
> > > > >
> > > > > Regards,
> > > > > tch.
> > > > >
> > > >
> > > > At one point in the past suagr-update-control did have the ability
> > > > to
> > > > look
> > > > for a schoolserver, adding the activities found there to the list
> > > > of
> > > > activities available from both sources. That went away with the
> > > > change
> > > > in
> > > > sugar's post 0.100 updater.
> > > >

Remember sugar's version of the microformat updater is not part of any OLPC
released image, that support was added after 0.98 was released. There has
been some features that have been neglected in the past then dropped with
folding in of the updater into sugar.

> > > > Jerry
> > > >
> > >
> > > Thanks for the feedback!
> >
> > The above worked via a DNS name, I'd rather see an avahi service search
> > used to gain the ip of the update server. The could open up the
> > possibility
> > of using a local lan machine as the source of the updates.
> >
>
> I don't recall seeing that in sugar master at least, but if someone has
> the
> time to upstream, it would definitely be another useful feature.
>

The updater code in sugar hasn't always been there, it used to live outside
of sugar[2].

Jerry


1. http://wiki.laptop.org/go/Software_updater
2. http://git.sugarlabs.org/sugar-update-control/mainline/commits/master
3. http://wiki.sugarlabs.org/go/Features