[sword-devel] InstallMgr

[Troy A. Griffitts]

Thank Matthew.  Yes Daniel, we have had an established standard for 
installing modules for quite some time which uses FTP for remote module 
installation.  I would like all of our client applications to support 
all of our officially supported install methods.

The reason for this is so we can assure a content provider that their 
content will be available to 'SWORD applications' if they:

x y z

Currently, we can say this, but we have to add a disclaimer: "JSword 
based apps will not work unless you also zip up all of your modules and 
make these zips available as HTTP downloads."

I wish for this disclaimer to shrink, not grow, so I am trying to herd 
in the development efforts and ask all frontend developers to ensure 
that their applications at least support the already longstanding 
installation policies in place.


Now concerning new methods, like HTTP access.  Matthew is correct that 
we hope to add support for this in the 1.6.x branch of the engine.  At 
that time, we will ask all frontend developers to expose this 
functionality as well so we can then give content creators one more 
option (CD, FTP, ... + HTTP) to distribute their content.


The details of how this will be implemented are being discussed, but 
whether we SHOULD implement HTTP access, I think is unanimous.

I would like for this be implemented in a which doesn't depend on 
scripts for minimum HTTP support for a repository.  Following the same 
theme as other methods: "Just expose your working SWORD module library 
via HTTP."

This is difficult to implement for us, but we can do it once in C++ and 
have all frontends get the new functionality, and then all content 
providers have an easy means to expose content.

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.

Imagine using your favourite SWORD application installer to install a 
library of all the materials your ministry uses to reach your people 
group.  Everything is just how you want it on your computer.
Now you can copy it to a CD as-is, and it is a valid installation source 
to any other SWORD frontend.  You can pass that CD to a church with a 
website and they can copy it as-is to their website and serve the entire 
library with SWORDweb.  They can point an FTP server to it as-is, and it 
becomes a valid remote installation source for their congregation or 
other people working in the same domain and running any SWORD client,
...
and in the future, they hopefully will be able to allow HTTP access to 
the same location as-is and it becomes a valid remote installation source.

The zip scripts and ls-LR files are all fine to help improve speed and 
reduce processor power, but I am willing to bite the bullet and do the 
work to make things functional without them, if it keeps this easy to 
propagate scenario available.

Am I helping explain my reasoning?

	-Troy.










Matthew Talbert wrote:
>> I think I caught your drift with the caps in your previous message, but it's
>> a bit discouraging and doesn't yet answer the problem I raised awhile back.
>>
>> To recap, because of security concerns with having anonymous FTP access, one
>> group I work with effectively denied us the ability to set up a repository.
>> If HTTP is not required of front-ends, then you MUST have an FTP repository
>> to get consistent coverage among the front-ends. I'm not hearing a clear
>> argument for why HTTP shouldn't become the standard except that "Our scripts
>> for generating zipped modules doesn't work reliably" and "it's hard to
>> create a list of modules from different formats." Are both of these
>> insurmountable?
>>
>> I'm trying to understand why FTP is the preferred method when HTTP is a
>> lower common denominator between providers. Could you explain that to me?
>>
>> My goal isn't to push an agenda but find a way to set up a repository that
>> will work with all front-ends but does not use anonymous FTP.
>>
>> Mildly discouraged,
>> Daniel
> 
> I don't think there's any need for discouragement Daniel. I believe
> what Troy is saying is that *frontends* should support FTP. He's also
> saying that he intends to add support for HTTP in the engine. At that
> point, both FTP and HTTP repositories will be possible and should be
> supported by all frontends. So the requirement isn't on the
> repositories being a certain way, but frontends being able to handle
> both types as a common denominator. Troy can correct me if I'm
> misunderstanding him.
> 
> I will be happy to see HTTP support for installmgr.
> 
> One additional request that I have would be to allow installing a
> single zip from somewhere on the file system. Will this be possible
> with the proposed implementation? I'm willing to help with this, as I
> want it in Xiphos and was intending to implement it there, but it
> would be better to have in the library.
> 
> Matthew
> 
> _______________________________________________
> 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