[Sugar-devel] [DESIGN] optional automatic updates

[Jerry Vonau]

> 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. 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?
 
> 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 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?

 
> > > 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.
> >
> > 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.

Jerry