[bt-devel] BibleCS / BibleTime on Windows

[Eeli Kaikkonen]

On Sat, 13 Feb 2010, Troy A. Griffitts wrote:

> Eeli,
>
> After looking at the dialog you posted, I revisited the code we changed
> in SWMgr to help the Xiphos guys on their Windows port.  I had forgotten
> that we added OS specific lookup paths at the end of the lookup algorithm.
>
> For Windows:
> $ALLUSERSPROFILE/Application Data/sword/mods.d/
>
> For Mac OSX:
> $HOME/Library/Application Support/Sword/
>
> I'll add these to the INSTALL doc.
>
> The core history behind the lookup logic is such that:
> Originally, SWORD just wanted to find a single path for modules: DataPath
> Then we added the idea of augmenting personal modules to the primary
> DataPath: ~/.sword
> Then to support mobile devices with flash memory, we added AugmentPath.
>
> Generally, a user installation isn't much more complicated than this.

I understand the logic. Still it doesn't meet what I see to be the
needs. I have at least these:

1. There should be one global path. It's the one you mention for Windows
and Mac. In Linux it's usually /usr/share/sword. This isn't necessarily
writable for the user. There should be a method in the engine to get
this path.

2. One private path for personal modules (in home dir). There should be
a method in the engine to get this path.

3. Augmented paths (for example for CD disk or USB stick or network
drive or any other location). There should be a method in the engine to
get these paths. It should be possible to save a new set of paths
without touching the config object/file explictly.

4. A way to configure 1-3 so that each can be used independently of
others. I haven't found a way to do this without bypassing the default
mechanisms.

5. There should be no surprises. If a path is taken off or added it
shouldn't affect to other paths. Currently this isn't true in either
way: adding may hide others, taking off may reveal others. This is why I
found the problems in the first place. If you create mods.d/ to a wrong
place or add SWORD_PATH env variable they hide some other paths, and if
you take them off other paths are revealed. This is clearly wrong. Also
requiring a mods.d directory to make a path valid is wrong. Of course
it's valid only if there's mods.d/ AND modules/ AND some modules, but it
shouldn't affect the search for other paths.

6. The final used path list should be an ordered set, not allowing
duplicates. Currently it's possible to add a path twice which doesn't
make sense.

7. All frontends should support all paths: global, private, augmented.
Currently this isn't true. Xiphos uses the default mechanism. As far as
I know it uses the global and private paths, but not augmented paths.
There is no way to use the default mechanisms so that adding augmented
paths in one app would add them to other apps. ~/.sword/sword.conf is
probaly ment for this, but is it actually used by any other app than
BibleTime?

8. BibleCS is a special case, but why? It should play well with other
apps - currently it requires that others do special tricks to play well
with it. The only working way is to support the same paths in all
frontends. Using the CWD should be optional for each app.  The
SWORD_PATH env variable doesn't work perfectly: if the user moves the
BibleCS installation, the path isn't updated (or is it?) and other apps
loose the path. The solution would be to install modules to the common
global or private location by default. Only if the user wants to use the
app as a "portable" app they should be installed to the application
path.

9. In my opinion the concept of "DataPath" and "AugmentedPaths" is
faulty. There's either zero, one or more paths. "DataPath" isn't
conceptually any different to "AugmentedPaths" if there are more than
one paths.

Number 5 is quite critical. I mentioned that finding a path shouldn't
affect to finding other paths. This of course would render the whole
current mechanism wrong, because it's based on the idea of finding only
the first valid path. I think a completely new mechanism is needed.  I
would add new API and methods. It could be done without affecting the
old system, but it doesn't help with cross-application compatibility
unless all apps use it. I was thinking about something like this:

/*
* These tell where modules can be found:
* GlobalDir: The system dependent directory for all users.
*            Recommended for the frontends. See getGlobalDir().
* PrivateDir:  The system dependent private directory of the current
*              user. Recommended for the frontends. See getPrivateDir().
* ConfFile: The directories mentioned in the default SWORD conf file of
*           the current user. Recommended for the frontends. Changing
*           the path list in this file affects all frontends which use
*           this. See getConfFilePathList().
* AppDir: The directory where the application binary is installed.
*         Use this if the frontend is a portable app.
* WorkingDir: The current working directory.
* SwordPath: The directory pointed to by the SWORD_PATH env var.
*/
enum PathType {GlobalDir, PrivateDir, ConfFile, AppDir,
               WorkingDir, SwordPath};

/*
* Sets the paths where the engine will try to find modules.
* Recommended path list for frontends is: GlobalDir, PrivateDir,
* ConfFile. If the config file is used and it duplicates some paths,
* or if some paths are otherwise duplicate, the final list will not
* include duplicates.
*/
void findModulePaths(list<PathType> paths);

/*
* Adds paths to the module path list. Use this after findModulePaths(),
* which see. Duplicates are left off. Use this only for special needs;
* PathType and findModulePaths() should be enough for most needs.
*/
void augmentModulePaths(list<SWBuf> paths);

/* Returns a list of unique paths where we try to find modules.*/
list<SWBuf> getUsedModulePaths();

/*
* Uses the same list which is returned by getUsedModulePaths() after
* calling findModulePaths() and possibly augmentModulePaths().
*/
void loadModules(bool allowDuplicateModules=true);


  Yours,
	Eeli Kaikkonen (Mr.), Oulu, Finland
	e-mail: eekaikko at mailx.studentx.oulux.fix (with no x)