<html><head></head><body>A few quick comments.<br>
<br>
If you're using http to grab the zips, we already have an http URL which will be sure to give you the latest zip-- the packager.<br>
<br>
If I implement the cache mechanism in the engine, I will use the same logic as what is in the packager to determine if any found zip is current.<br>
<br>
The code for the packager is in the crosswire-java svn repo. You should be able to find the servlet with a grep. Old sucky code I'm not proud of but works.<br><br><div class="gmail_quote">Chris Little <chrislit@crosswire.org> wrote:<blockquote class="gmail_quote" style="margin: 0pt 0pt 0pt 0.8ex; border-left: 1px solid rgb(204, 204, 204); padding-left: 1ex;">
<pre class="k9mail">On 07/20/2013 03:05 PM, DM Smith wrote:<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">On Jul 20, 2013, at 5:42 PM, Chris Little <chrislit@crosswire.org> wrote:<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">On 07/20/2013 07:14 AM, Martin Denham wrote:<br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #8ae234; padding-left: 1ex;">They should be there again now. And Bible depends on the av repository.<br /><br />See this thread for more info:<br /><a href="http://svn.crosswire.org/pipermail/jsword-devel/2013-April/004639.html">http://svn.crosswire.org/pipermail/jsword-devel/2013-April/004639.html</a><br /><br />It is a real shame the av zips are not created automatically.</blockquote><br /><br />Or...<br />It's a real shame that JSword doesn't use the repositories correctly, according to their intended usage.</blockquote><br />Yes it is a shame. I'm almost done w the code to use the expanded repository via ftp. This will be with the release after next.</blockquote><br />Awesome.<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;"><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">Or...<br />It's a real shame you don't write a cron job that can update the ZIPs nightly, if necessary. (Maybe Karl can help you, if he has a script to update ZIPs in his repository.)</blockquote><br />Can anyone point me to the code that does the zipping? While coding it up is trivial, there's no point to re-inventing the wheel. Just port the code to a loop.<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #ad7fa8; padding-left: 1ex;">The latter is probably more useful at this point and more urgent since I am going to write a cron job to delete the ZIPs on occasion.</blockquote><br />Please don't do this until we have had a chance to write the script.</blockquote><br />Yeah, it's not urgent. It can wait a while. And I only intend to have it <br />run once a week or so.<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">What would the purpose of doing the mass deletes? Currently JSword uses the file time to determine whether the module has changed. Since our frontends do not advertise updated modules, this is no big deal. We've got the mechanism written to use the conf version field, but it is not in the frontends yet.</blockquote><br />There are a couple of reasons to clear out the cache on occasion. The <br />web download applet will generate ZIPs for updates and new modules, but <br />don't remove pulled modules (and sometimes I forget to do it manually). <br />We also get people who think they're really smart and start feeding the <br />download applet things like NIV and NKJV. And the applet will happily <br />package those for them (except that they are empty of content). So it's <br />nice to clear out those sorts of files from the server.<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">If the purpose is to ensure that old stuff is appropriately deleted, then a script comparing module conf to zips deleting those that don't match would be better. This is even simpler to write than the zipper program. This could be added to the zipper program.</blockquote><br />Sure, there are other ways of handling the issues.<br /><br /><blockquote class="gmail_quote" style="margin: 0pt 0pt 1ex 0.8ex; border-left: 1px solid #729fcf; padding-left: 1ex;">BTW, Troy's position has been that it is OK to go to the zip cache first and failing that get the module by parts. But that there should be no requirement of a frontend to have the zips. Many have noted that getting the zip is faster and more reliable than getting by parts.</blockquote><br />At present, I believe that is a bad position. Shortly after updates, <br />ZIPs and the module parts can get out of sync so that, e.g., you think <br />you're downloading version 2.0 of a module, but you're actually <br />downloading 1.0 since that's what the ZIP is because no one has <br />downloaded through the applet, causing the ZIP to update. And no amount <br />to trying to update from the ZIP is going to update to 2.0 until someone <br />else hits the download applet.<br /><br />A cron job running an update script would at least mean that both the <br />mods.d.tar.gz and ZIPs get updated at approximately the same time.<br /><br />--Chris<br /><br /><br /><br /><hr /><br />sword-devel mailing list: sword-devel@crosswire.org<br /><a href="http://www.crosswire.org/mailman/listinfo/sword-devel">http://www.crosswire.org/mailman/listinfo/sword-devel</a><br />Instructions to unsubscribe/change your settings at above page<br /></pre></blockquote></div><br>
-- <br>
Sent from my Android phone with K-9 Mail. Please excuse my brevity.</body></html>