[Sugar-devel] [DESIGN] Extending activity microformat spec to include optional olpc_activity_size

[Anish Mangal]

On Mon, Nov 29, 2010 at 1:48 PM, Daniel Drake <dsd at laptop.org> wrote:

> On 29 November 2010 03:06, Bernie Innocenti <bernie at codewiz.org> wrote:
> > If the size were only needed at download time, then there would be no
> > need to perform a separate query: the size is already present in
> > Content-Length header.
> >
> > I think Anish wants to know the size beforehand to show it in the list
> > of update candidates.
>
> OK. If it's really important to save 1-2 seconds of update time (on a
> download thats then going to take probably more than a minute, perhaps
> substantially more) I'd suggest just dropping this part.
>
>
In my little testing experience, this takes a lot more than 1-2 seconds for
a group of activities (such as this [1]). I could run more formal tests if
you want. Also, I do feel it these paltry few seconds (when compared to
probably minutes of download time) are of importance because of where this
delay happens.

The updater works as
(1) checking and listing the updates
(2) the user selecting which updates to be installed
(3) downloading and installing selected bundles

The delay in question happens at (1) while the user is waiting for the list
to appear (and that's why its important). After the user has initiated the
download (3), he doesn't really need to be near the computer while the
process takes minutes (or so i think).

> The schoolserver could cache the xo bundles. In Paraguay, this wasn't
> > happening for the largest ones due to size limits in the default
> > configuration of Squid. So we increased the maximum size for .xo.
>
> This would suggest that the size query time is really fast then, no
> need to change the microformat. No?
>
> > True, but distributing the bundles *to* the schoolservers is still on a
> > do-it-yourself basis, with rsync scripts, cronjobs, puppet and all the
> > associated complexity.
>
> Yet this is well documented and widely implemented practice. (There
> isn't another present day option that scales)
>
> > In the real world, most bundle downloads will probably come from sources
> > other than the deployment HQ. Think of Doom & Super Vampire Ninja Zero!
> > So the generic HTTP caching offered by squid is probably going to be a
> > better use of the school's bandwidth and disk space.
>
> But these activities aren't covered by the updater, right?
> The only ones that get covered in these queries would be the ones
> listed on the deployment-controlled activity group.
> Or is something changing?
>
>
While we're discussing this, could you explain to me the implications of
adding an optional parameter to the spec.

Your idea of only getting the size if the available bundle is newer or not
presently installed makes sense. I'll try and include this in the code.

[1] http://wiki.paraguayeduca.org/index.php/Actividades_Dextrose_1

Daniel
>

-- 
Anish
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.sugarlabs.org/archive/sugar-devel/attachments/20101129/c93381f4/attachment.html>