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 <ransom1...@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@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@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@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@crosswire.org
http://www.crosswire.org/mailman/listinfo/sword-devel
Instructions to unsubscribe/change your settings at above page
