[sword-devel] ftptrans.h

DM Smith dmsmith555 at yahoo.com
Mon Sep 10 16:09:43 MST 2007


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 <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?
>>
>> 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 at 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 at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page




More information about the sword-devel mailing list