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

[Bernie Innocenti]

On Mon, 2010-11-29 at 08:18 +0000, Daniel Drake wrote:

> OK. If it's really important to save 1-2 seconds of update time

>From Paraguay it was more like 1-2 seconds per activity.

>  (on a
> download thats then going to take probably more than a minute, perhaps
> substantially more) I'd suggest just dropping this part.

Agreed. It's not a necessary feature, imho. Code and protocol simplicity
are more important in this case.


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

Each GET, even if content is in the squid cache requires a remote HTTP
query to check for stale data in the cache. With the typical ping times
of 500-1000ms, you end up waiting a couple of seconds.

Sure, we could special-case .xo bundles in Squid to avoid the extra
check, since the bundle name changes when a new version of the bundle is
released. Yet another optimization kludge.

Ah, forgot another important detail! On ASLO, query to files are being
redirected to the mirrors! So checking for the size would involve 2
queries.


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

Isn't the transparent web cache already a good enough solution for
activity distribution?


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

Indeed, the new updater doesn't support it, but I thought that the old
one could check the update URL specified in the activity.info. I
remember someone (probably Scott or Michael) explaining this obscure
feature to me.

I also remember asking the obvious question: "what if I want to override
the URL hard-coded in the bundle?" And the clever answer I got was: "the
updater checks the global update URL first and the activity-specified
URL second."

Ok, this is not relevant to the current conversation because the new
microformat updater does not support this. All these design discussions
remind me how much time we're wasting by reinventing the wheel without
the resources to make it fully round :-(

-- 
   // Bernie Innocenti - http://codewiz.org/
 \X/  Sugar Labs       - http://sugarlabs.org/