[sword-devel] virtual modules

[Chris Little]

Martin Gruner wrote:
>>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. 
> 
> I don't see too much gain here, at least judging from a BT perspective. If 
> frontends have to disasseble the resulting OSIS code again, it would perhaps 
> be even more work. This depends on how the frontends want to present the 
> module.

I think that, in a sense, some of these proposed virtual modules won't 
be useful to frontends like BibleTime that already have similar 
functionality implemented. I know that BibleTime, BibleCS, and SwordWeb 
already have some form of parallel Bible view--and I don't happen to 
know about GnomeSword or BibleStudy. And if a frontend doesn't wish to 
make use of a parallel virtual module, it is quite free not to do so.

But for new frontends or developers who wish to, for whatever reason, 
rely on Sword to do this kind of work, the parallel module will provide 
them a ready-made module to render in a format consistent with the other 
content (OSIS).

>>A NOTES virtual module would do the same thing, 
>>returning just the notes (converted to OSIS) from a specified module for
>>a specified verse. 
> 
> That's what EntryAttributes were created for.

EntryAttributes are a method of retrieving the notes from the base 
module. What I'm proposing, though, is dynamically creating a new module 
(from the perspective of SWMgr), which happens to contain a set of notes 
copied from the base module (whether via EntryAttributes or otherwise).

BibleTime and BibleCS use EntryAttributes to pull individual notes upon 
mouse-over, but the notes virtual module would pull the full set of 
notes for a verse and return it as if it were a module itself (akin to 
the the relationship between the Geneva Bible and the Geneva notes 
modules we have or the NET Bible and accompanying notes we were testing).

This was a specific request that came up in discussions of the NET 
Bible, so I would like to see something consistent with this style of 
presentation be provided by each of the major frontends at least. (Full 
disclosure: In the discussions, Barry Drake commented that he preferred 
the text module + commentary module format of the old NET Bible test 
modules to an integrated, single module with mouseover popup notes. That 
certainly makes sense when you consider the length of the NET Bible 
notes. My whole concept of virtual modules grew out of the desire to 
represent modules correctly (in terms of OSIS documents) and to 
integrate them more completely than 2 distinct modules would permit, but 
to also allow 2-window rendering for the user, to accomodate Barry's 
recommendation.)

> Another case where I could imagine a good use for it would be the "on-the-fly" 
> generation of Interlinear Virtual Modules (tm) ;) (based on Strong's 
> numbers), but there frontend presentation-markup issues come in again.

Yeah, I considered something akin to that a long time ago, but had no 
clue how it might be achieved. Then again, we didn't have as much 
Strong's marked content at the time, and I was thinking of a purely 
frontend-side implementation.

Maybe we should have a virtual module idea contest. :) We could have 
people come up with good ideas for realtime algorithmic manipulation of 
existing data--bonus points go to people who dream up things that are 
actually useful or that Logos hasn't already implemented. :)

Troy made a comment to me when we were in Philadelphia for the last OSIS 
conference about Sword (the library) nearing a feature-complete state, 
where we've pretty much got the capability to do all the basic stuff 
that anyone else is doing. Going forward, most of the work in Sword 
(ignoring new module acquisitions/licensing and frontend work) is going 
to be in the area of doing NEW things like this with our existing data.

> This is a good and innovative concept, but probably should be thought about 
> more in order to create a consistent structure in the API. Maybe we should 
> store this for our discussion about Sword 2?

I did some prototyping on Wednesday, to see what the structure and 
interface ought to be, and I think I've got a fairly solid idea already. 
  My objective was to do something along the lines of the EchoMod class 
already in the library (which, in case you missed it, is a test module 
driver that just returns the key value it is given as text). I started 
by deriving a general virtual module class from SWText (figuring SWCom 
and SWLD-derived virtual module classes would needed eventually). Then I 
derived an EchoMod-type class from this virtual module class, plugged it 
into SWMgr, and tried it out.

But I realized that virtual modules don't actually have anything in 
common, necessarily, from the API side of things, so I removed the 
intermediate layer and derived the EchoMod class directly from SWText, 
which is probably how I will do the parallel and wdiff classes. The 
notes class, of course, derive from SWCom.

The way I would propose telling the virtual modules which base modules 
to referece is through the existing config system (including .conf files 
on disk). For example, a parallel module would have a real on-disk .conf 
file that specifies something like "BaseTexts=KJV;ASV;WEB" along with an 
actual module name like "[EngParallel]". The driver might be 
ParallelText. This method permits multiple simultaneous collections of 
parallel "modules", saved on disk. It then becomes the frontend's 
responsibility (if it chooses to use the whole parallel text virtual 
module system) to create and maintain the internal config, by creating 
an interface for adjusting the BaseTexts value. (Writing the internal 
configuration values to an on-disk .conf file would primarily be the 
library's responsibility, though there will be some issues regarding 
where to place .conf files.) The wdiff, word-aligned interlinear, and 
notes virtual modules would be similarly implemented.

If a .conf file is absent, the module would never show up in SWMgr. And 
if the frontend provides no means for creating the .conf file in the 
first place, obviously there's no expectation that it would support the 
output of the module either (though users could potentially create .conf 
files that the library would recognize, either by hand or with another 
frontend).

I think it's actually all a lot simpler and more easily implemented than 
it may sound--not to mention completely unobtrusive to frontend 
developers who wish to ignore the funtionality.

--Chris