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
_______________________________________________
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
