My understanding is that one of the first things that a "front-end"
needs to do is instantiate SwMgr and let it find all the modules that
are available. This detection is used to populate Tabs or drop-down
lists so the end-user can switch from module to module.
Once there are a lot of modules installed, this can take a long time.
The LcdBible front-end is oriented to the "niche" of older (dinosaur)
computers, and the SwMgr detection can be lengthy.
(Note: I'm not that knowledgeable about the sword-api, so it may be
some other manager object and not SwMgr.)
Has consideration been given to "caching" which modules were
detected? Perhaps there could be something like a time-stamped file
such as ModulesCacheInfo.conf in the mods.d directory?
The front-end or the sword-api could read just this file to get a
"quick and dirty" detection accomplished. My impression is that the
specific list of modules installed doesn't change very often. Usually,
the list would increase rather than decrease over time, at least for
end-users.
The InstallManager might have some convention to indicate that SwMgr
has "stale" information and trigger a "cache refresh".
(Granted, modules can be installed without using the InstallManager,
so this would be too simplistic.)
I've thought about having LcdBible use a "worker thread" for SwMgr
detection to expedite getting "launched", but this add complexity and
has other problems.
_______________________________________________
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
