Troy A. Griffitts
scribe at crosswire.org
Mon Sep 10 11:45:04 MST 2007
First reasoning, then a couple possible ideas.
The reason we traverse the tree and copy files one by one is because the
simple requirement for posting a SWORD repository is only that you can make
a currently working installed sword library available via FTP services from
your server. This is a good thing and we wish to keep this ease of
Some ideas toward your request for improvement: It is fairly common that an
FTP server will allow a request to get a <directory>.zip and will
automatically zip up the directory for you and transfer it. InstallMgr,
when downloading the DataPath directory could _try_ <DataPath>.zip and see
if it is available.
We currently have 1 caching mechanism in place: mods.d.tar.gz If this
exists, we use it, otherwise we grab the mods.d/*.conf files one by one. We
could do something similar where we check, e.g. <Repository
Path>/../packages/raw/<Mod>.zip and use it if it exists.
DM Smith <dmsmith555 at yahoo.com> wrote:
>The BAO module has about 175 images. Are these downloaded one by one?
>What happens if there is a failure on downloading, say, the 135th image?
>I would think that with an image rich module that there is no constraint
>on the number of images it might hold. Is there a good way to improve
>the reliability of the transfer of the entire module?
>Martin Gruner wrote:
>> is there a reason why
>> int copyDirectory(const char *urlPrefix, const char *dir, const
>> const char *suffix);
>> in ftptrans.h is not virtual? This would allow frontends to reimlement on
>> higher level than getURL only. The current implementation of
>> has the weakness that the counter for total data to be transferred
>> as new directories are found and transferred. You can see this with the
>> module from Karl Kleinpaste, for example. The status reporter 'readjusts'
>> progress as it discovers the directory with the images, which holds the
>> actual data.
>> Can we change the function definition above to make it virtual?
>> God bless,
>sword-devel mailing list: sword-devel at crosswire.org
>Instructions to unsubscribe/change your settings at above page
More information about the sword-devel