[sword-devel] virtual modules
chrislit at crosswire.org
Wed Jan 18 14:34:52 MST 2006
Martin Gruner wrote:
> please help me understand how your proposal differs from the entry attribute
> system that we have now. IIRC that is what BibleTime uses to extract
> footnotes, for example.
I admit I haven't even looked at the entry attribute system. I think
that post-dates most of my experience with the API, so I'll need to
learn it. In any case that could, I believe, represent a change to the
underlying method by which the virtual module is constructed rather than
the API's exposure of the virtual module itself.
What I'm proposing is that the API would, in addition to real modules
like the KJV, GerLut, MHC, etc., expose modules that aren't represented
explicitly through a module stored on disk.
For example, a PARALLEL virtual module, assuming which translations to
present in parallel were somehow specified, would pull a single verse
from translations A, B, & C, surround them with <verse> tags, and pass
the result back through standard API functions for getting a verse from
a regular module. A NOTES virtual module would do the same thing,
returning just the notes (converted to OSIS) from a specified module for
a specified verse. And a VERSEDIFF virtual module would produce
something like the wdiff results that have been under discussion, for a
specified pair of modules and a specified verse.
I would probably try to expose the virtual modules through SWMgr in a
similar manner to the way the real ones are, but we would need to be
certain that they can be distinguished, should a frontend desire to hide
some or all of them.
Does this make sense? Do you see any flaws in the idea? Is it worth
implementing, in your opinion?
More information about the sword-devel