<div class="gmail_quote">On Mon, Nov 29, 2010 at 1:48 PM, Daniel Drake <span dir="ltr"><<a href="mailto:dsd@laptop.org">dsd@laptop.org</a>></span> wrote:<br><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<div class="im">On 29 November 2010 03:06, Bernie Innocenti <<a href="mailto:bernie@codewiz.org">bernie@codewiz.org</a>> wrote:<br>
> If the size were only needed at download time, then there would be no<br>
> need to perform a separate query: the size is already present in<br>
> Content-Length header.<br>
><br>
> I think Anish wants to know the size beforehand to show it in the list<br>
> of update candidates.<br>
<br>
</div>OK. If it's really important to save 1-2 seconds of update time (on a<br>
download thats then going to take probably more than a minute, perhaps<br>
substantially more) I'd suggest just dropping this part.<br>
<div class="im"><br></div></blockquote><div><br></div><div>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.</div>
<div><br></div><div>The updater works as</div><div>(1) checking and listing the updates</div><div>(2) the user selecting which updates to be installed</div><div>(3) downloading and installing selected bundles</div><div> </div>
<div>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).</div>
<div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div class="im">
> The schoolserver could cache the xo bundles. In Paraguay, this wasn't<br>
> happening for the largest ones due to size limits in the default<br>
> configuration of Squid. So we increased the maximum size for .xo.<br>
<br>
</div>This would suggest that the size query time is really fast then, no<br>
need to change the microformat. No?<br>
<div class="im"><br>
> True, but distributing the bundles *to* the schoolservers is still on a<br>
> do-it-yourself basis, with rsync scripts, cronjobs, puppet and all the<br>
> associated complexity.<br>
<br>
</div>Yet this is well documented and widely implemented practice. (There<br>
isn't another present day option that scales)<br>
<div class="im"><br>
> In the real world, most bundle downloads will probably come from sources<br>
> other than the deployment HQ. Think of Doom & Super Vampire Ninja Zero!<br>
> So the generic HTTP caching offered by squid is probably going to be a<br>
> better use of the school's bandwidth and disk space.<br>
<br>
</div>But these activities aren't covered by the updater, right?<br>
The only ones that get covered in these queries would be the ones<br>
listed on the deployment-controlled activity group.<br>
Or is something changing?<br>
<font color="#888888"><br></font></blockquote><div><br></div><div>While we're discussing this, could you explain to me the implications of adding an optional parameter to the spec.</div><div><br></div><div>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.</div>
<div> </div><div>[1] <a href="http://wiki.paraguayeduca.org/index.php/Actividades_Dextrose_1">http://wiki.paraguayeduca.org/index.php/Actividades_Dextrose_1</a></div><div><br></div><blockquote class="gmail_quote" style="margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;">
<font color="#888888">
Daniel<br>
</font></blockquote></div><br>-- <br>Anish<br>