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 _______________________________________________ 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
