[sword-devel] InstallMgr details.

[Manfred Bergmann]

Am 15.05.2009 um 06:58 schrieb Troy A. Griffitts:

> To understand the design decisions for InstallMgr, you have to have  
> a basic understanding of the SWORD API:
>
> Libraries of modules are exposed as SWMgr objects.
> An SWMgr object can be easily created from a local path:
>
> SWMgr localLibrary("/path");
>
> So for local sources, you don't need InstallMgr to obtain an SWMgr  
> object.
>
> InstallMgr has a new object: InstallSource which houses the  
> configuration information for a remote source and can give back an  
> SWMgr object which represents that remote library.
>
> InstallMgr provides new SWMgr features useful when writing an  
> install client like: compare 2 SWMgr objects and tell you which  
> books are new, old, updated, etc.
>
> InstallMgr can install TO an SWMgr.  This sounded like a clever  
> idea, as an SWMgr has the concept of a 'primary path', but in  
> hindsite, we only will probably ever support installing TO a local  
> directory, so this has added confusion.  The use case was:
>
> SWMgr defaultLocalSWORDLibrary;
> installMgr.installModule(&defaultLocalSWORDLibrary, "D:\\", "KJV");
>

I think that actually there doesn't need to be a difference between a  
remote or local module repository except that if the repository is not  
of protocol type "file://" then it should have the option to copy  
modules into a local repository.

Differenciating to much between the two makes things more complicated  
than they need to be for an API user.
As an engine user I would like either InstallMgr or SWMgr handle both  
situations transparently.
When speaking of remote module repositories instead of install sources  
I would rather say SWMgr should handle all cases.



Manfred


>
>
> Greg Hellings wrote:
>> 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.
>> --Greg
>>> 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
>>>
>> _______________________________________________
>> 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