[Sugar-devel] [DESIGN] optional automatic updates

[Martin Abente]

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


>
> Jerry
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20140807/6fb07dd1/attachment-0001.html>