[sword-devel] InstallMgr

[Eeli Kaikkonen]

Troy A. Griffitts wrote:

> 
> On top of that, we may add what I've been labeling as CACHING / 
> OPTIMIZATION mechanisms to make downloading quicker, but these will 
> require the content providers be more savvy, possibly implement cron 
> jobs to zip up folders, etc.  But these mechanisms will be optional for 
> the content providers.  They will not need to do these things to have a 
> valid repository.
> 

I'm trying to keep up with this discussion, but I don't know if I have 
followed closely enough. Anyways, I wonder why this is so complicated. 
There have been some discussion long time ago about zip versus a file 
tree. Why the modules have to be unzipped in the server at all? Why not 
just have one modules.conf.gz (or whatever) and all modules as zip files 
in a standard directory structure? As some have said, it would be good 
to have raw zip support in the engine anyways. If the http support is 
not there yet and we want to keep the old non-zipped ftp directory 
structure when using ftp, why not let the http support have a different 
directory layout with zipped modules only? That way there would be no 
problem with http file lists at all.

I don't know if I was clear enough, so I try to rephrase it:

1. We need to support a non-zipped directory structure with ftp 
(backwards compatibility).

2. We need to support http.

3. We don't need to support the old, standard non-zipped directory 
structure with http because it's not needed for backwards compatibility.

4. We need to support local raw zip files in the engine level.

5. We can combine 2, 3 and 4 by using a simple directory stucture and 
zip files with http.

The simple directory stucture could be for example:
     - http://host/path/to/sword/downloads/
     - path/to/sword/downloads/mods.d.tar.gz
     - path/to/sword/downloads/KJV.zip
     - path/to/sword/downloads/ESV.zip
     - ...


--Eeli Kaikkonen