<div class="gmail_quote">On Mon, Nov 8, 2010 at 7:48 AM, Greg Hellings <span dir="ltr">&lt;<a href="mailto:greg.hellings@gmail.com">greg.hellings@gmail.com</a>&gt;</span> wrote:<br><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">

<div class="im">On Sun, Nov 7, 2010 at 8:28 AM, Jonathan Morgan &lt;<a href="mailto:jonmmorgan@gmail.com">jonmmorgan@gmail.com</a>&gt; wrote:<br>
&gt; A lot here depends on evaluation of pros and cons.  I personally support<br>
&gt; HTTP, zipped modules, and one central file (like mods.d.tar.gz) to give a<br>
&gt; list of all the books and where to find them for at least some of the<br>
&gt; following reasons.  I will try and capture why succinctly:<br>
&gt; For ZIPs:<br>
&gt; 1. Minimising the number of GETs issued (and potentially file size and<br>
&gt; download speed): I think this is particularly important for loading the<br>
&gt; initial list of modules, which should preferably be as fast as it possibly<br>
&gt; can be.  It also makes a difference for image modules like Dore&#39;s Woodcuts<br>
&gt; with lots of loose files (which I remember taking a very long time to<br>
&gt; install with Install Manager).<br>
<br>
</div>I&#39;m not sure what your metrics are, but Ubuntu&#39;s apt for me hits about<br>
70+ files on a half dozen or more servers to update its cache and this<br>
takes less than 2 seconds.  It takes installmgr almost no time to<br>
process a single refresh.<br></blockquote><div><br>Well, I just tried it with Xiphos on Windows and it took mine 4 or 5 seconds to refresh the main CrossWire repository.  My enduring memory of InstallManager is that it feels slow.  My guess is that the difference is due to going from Oz to US rather than from US to US (I do have a reasonably fast network connection).  Apt on Ubuntu is a lot faster, but that is because it is mirrored to an Oz site and doesn&#39;t have the latency.<br>

<br>I&#39;m assuming that we have among our target audience:<br>1. People who are on the other side of the world from the US.<br>2. People who do not have a fast network connection.<br><br>The other thing is that I believe the Install Manager case we are testing <b>is</b> in fact the case I advocate: It is grabbing mods.d.tar.gz rather than doing FTP file traversal and grabbing one conf file at a time.  I don&#39;t know how to test it without rebuilding SWORD, but I think the InstallMgr would grab one conf file at a time and so have a lot of latency from places like here.  This (a repository not requiring mods.d.tar.gz) is the simple FTP server setup that is being promoted.<br>

 <br></div><blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
The main problem is that we are not setup to handle display from<br>
multiple sources and also not to refresh from all the repositories at<br>
once, they have to be refreshed one at a time.  This isn&#39;t so ideal to<br>
the user&#39;s experience, but that&#39;s how it is done.  I really doubt we<br>
need to worry about the performance of hitting 30 or 40 repositories<br>
if that is what the user selects to enable - and if we do, then that<br>
indicates we need to rethink how we&#39;re hitting the repositories,<br>
because the limit certainly isn&#39;t the number we&#39;d be hitting at that<br>
point.<br></blockquote><div><br>If the vision is having individual publishers publishing their own work, then having 30 or 40 repositories would be a big success - and I don&#39;t think we can scale to that point (I don&#39;t see any prospect of that any time soon, but if that is the vision it&#39;s worth thinking about whether we can support it).<br>

<br>Jon<br></div></div>