> Remote repositories have concepts like 'refresh from remote source' (apt-get
> update)
>
> Local repositories usually aren't 'entered' in a list by a user, though I
> suppose they could be if it was useful. Practically there is usually 1
> local source (a CD or USB drive) and the user can Browse... to the location.
> This is not easily replicated for remote sources. They are typically
> 'configured' and their configuration stored for future reference.
In Xiphos, we do allow entering them into a list. Therefore, we have
to save their 'configuration' (which is essentially just the path),
somewhere so we can refer to it later. In fact, I believe we store it
in the normal configuration file for remote sources, however, we can't
get it as "just another source", it has to be gotten via our own
function. I would much rather the distinction between the two went
away, so we could say "install this module from this source" and not
have to worry about whether it's local or remote. I depend on this
local install functionality quite a bit as I do testing on different
machines, and keep a huge repository of modules on a network share
that I can install as needed. It took quite a bit of (imo,
unnecessary) work to write code that behaved differently for the local
installs so that they worked properly.
Another consequence of the local install special case, is that it
doesn't provide us with a progress callback function (that I'm aware
of). This means that for installing a large number of modules from a
local source, the app appears to do nothing for quite some time then
is suddenly finished.
>
> So, while the difference between local and remote is there, a remote FTP
> source and a remote HTTP source will likely be much less different.
> Some I can think of: We now have just added support in 1.6.0 for
> non-anonymous FTP, so the user can input username/password if necessary--
> useful for access to a private beta repository. We have supported Passive
> FTP as an option. With HTTP access, we might also add HTTP proxy features.
> These all require frontend user preferences.
As Greg points out, user/pass and proxies apply to both HTTP and FTP.
> 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.
No, but you do have to create the SWMgr yourself, remembering the
correct settings to keep it from grabbing all modules it finds
anywhere, and you do have to store the path somewhere.
> 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.
And this would also be useful for the local install case. I think in
either case we compare the two SWMgr's manually to decide what is
updatable, but it would be preferable to use InstallMgr to do that
with both cases.
> 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");
>
> But this is too simplistic a use case to be practical.
This is how we use InstallMgr for both local and remote cases, because
it is the only way that gives us control over where the module ends
up. Of course, we have to construct the SWMgr with the destination
path and prevent it from looking up other modules, plus make sure the
path is writable, for this to work properly. It would be better, imo,
to allow installing to a *path* without needing to create an SWMgr
first. (Keep in mind that I have a rather large number of modules, so
every creation of SWMgr takes a few seconds)
> (for history, it used to be, at a time we only supported CD (well, local)
> installations:
>
> int InstallMgr::installModule(SWMgr *destMgr, const char *fromLocation,
> const char *modName);
> // which I don't hate
this is the same as the example above, correct?
> /** call to install a module from a local path (fromLocation) or remote
> InstallSource (is) (leave the other 0)
> */
> int InstallMgr::installModule(SWMgr *destMgr, const char *fromLocation,
> const char *modName, InstallSource *is = 0);
>
>
> So, InstallMgr can either install FROM a local path (historically the
> initial impl), or remote InstallSource.
>
> When we decide to majorly break backward compatibility for the interface
> cleanup and remove all deprecated methods, InstallSource will probably get a
> c-tor(const char *path), and the 2nd parameter will just go away.
The path being the place to install to or from? It would seem better
to me to have local sources part of the normal source list (as others
have mentioned), and have a path to install to. Xiphos is perhaps
unique in allowing the user to specify where they want to install
modules, either personal or shared location. In the future, I hope to
allow multiple install locations. At present, the lack of a method to
give the destination prevents this from being done cleanly.
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
