[sword-devel] virtual modules

[Chris Little]

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?

--Chris