[sword-devel] InstallMgr

Greg Hellings greg.hellings at gmail.com
Thu May 14 21:38:02 MST 2009

On Thu, May 14, 2009 at 11:29 PM, Matthew Talbert <ransom1982 at gmail.com> wrote:
>> Does it require a difference (for the C++ front ends) to add support
>> for FTP InstallMgr methods than it does for them to add a file://
>> version?  It seems that, if so, this is a problem with the design of
>> InstallMgr.  I would imagine that the interface between SWORD and the
>> application would be identical in all those cases -- all the
>> application needs is to retrieve the information and provide a way for
>> the user to input new locations.  I get the impression from your
>> previous messages that the front ends will need to change when you add
>> HTTP support to the library then front ends will need to add another
>> portion to their install manager that allows the user to create HTTP
>> install locations separate from FTP or file:// ones -- is that the
>> case?
> The interface is different for local installations than it is for FTP
> installations. For local installations, you must create an SWMgr that
> points to the location of the modules to be installed, then you can
> get a listing of the modules available (but you must be careful to not
> augment the path with HOME/.sword or other locations or it won't
> work). For FTP, it also creates an SWMgr, but it does it itself, and
> exposes the list of available modules. This difference is why Xiphos
> couldn't really use a local source until 3.0. No one had figured out
> how it was supposed to work :)

I see -- it seems to me that method doesn't take nearly as much
abstraction as it should.  I should imagine that a client application
could simply create an InstallMgr object and pass it the string that
it ought to search for.  If the string is file://, ftp://, http://,
cifs:// or \\host or whatever shouldn't much matter in my mind.  The
URI should be parsed and the proper actions taken within InstallMgr.
Why was it done with a different class for each type, forcing the
client app to handle the parsing and take each experience differently?
 Inherently that will lead to different apps supporting or not
supporting certain of the features (the example that you just
mentioned, for instance).  If there was just the matter of "Create an
InstallMgr object, ask it what's available, tell it to install to
such-and-such a writable location" then as the library expanded
support for HTTP, SFTP, SomeFutureTP the applications would not even
need to know or care.


> 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

More information about the sword-devel mailing list