Troy,
Either way would be good and both would be a code change of about the
same magnitude.
For the beta modules, the ../packages would need to be changed to ../
betapackages.
Personally, I suggest the latter, even with this adjustment, because
the files are already cached there.
The code looks pretty straight forward that even I could do it. If
you'd like.
Serving Him Together,
DM
On Sep 10, 2007, at 2:45 PM, Troy A. Griffitts wrote:
> 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
> publishing.
>
> 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.
>
> Any thoughts?
>
> -Troy.
>
>
>
> DM Smith <[EMAIL PROTECTED]> 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?
>>
>> In Him,
>> DM
>>
>> Martin Gruner wrote:
>>> Hi,
>>>
>>> is there a reason why
>>>
>>> int copyDirectory(const char *urlPrefix, const char *dir,
>>> const
>> char *dest,
>>> const char *suffix);
>>>
>>> in ftptrans.h is not virtual? This would allow frontends to
>>> reimlement on
>> a
>>> higher level than getURL only. The current implementation of
>> copyDirectory
>>> has the weakness that the counter for total data to be transferred
>> increases
>>> as new directories are found and transferred. You can see this
>>> with the
>> BAO
>>> 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,
>>>
>>> mg
>>>
>>
>> _______________________________________________
>> sword-devel mailing list: sword-devel@crosswire.org
>> http://www.crosswire.org/mailman/listinfo/sword-devel
>> Instructions to unsubscribe/change your settings at above page
>>
>>
>
>
>
> _______________________________________________
> sword-devel mailing list: sword-devel@crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
_______________________________________________
sword-devel mailing list: sword-devel@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
