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

[Daniel Drake]

On 30 November 2010 07:11, Bernie Innocenti <bernie at codewiz.org> wrote:
> 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?

Seems to me like you just made the argument "its not"
It also doesn't work well for the first user who downloads the
activities (especially when there are big ones like Scratch), stops
working completely when the connectivity goes down even if everything
is cached, and doesn't work at all with offline schools.

It is easy to work with the XS here, just drop activity files in a
directory or put them on a USB disk within a certain directory and
plug it into the XS.

It seems to me that this whole discussion is a bit bogus anyway, since
(judging by later messages in this thread) Anish's code was querying
all activity metadata (like size) even when it had nothing to do. So
if you had 31 activities installed, and it queried the group page and
discovred that 0 updates were available, the code would still query
make 31 queries (determining file sizes) for no reason. I figure that
if he corrects this behaviour then the problem is pretty much solved
(or at least deserves re-evaluation).

Daniel