[sword-devel] virtual modules

[Troy A. Griffitts]

Hey Chris,
	I've been listening to the discussion and ideas but haven't had too 
much time to comment.  I like the idea of providing these 'virtual 
modules' as dropin solutions for frontend developers.  It's a great 
idea.  I think we discussed previously that I would like for us to add 
an 'extras' directory or similar to the engine source where we can dream 
and place code that _uses_ the engine for unique things.  What do you 
think about your SWModule subclass idea (whether from EchoMod, SWText, 
SWCom, or whavever) being available from there and utilized by a 
frontend with something like:

#include <parallelmodules.h>

SWModule *parallel = new ParallelModules();
parallel->addModule(mgr->getModuleByName("KJV"));
parallel->addModule(mgr->getModuleByName("ASV"));
parallel->addModule(mgr->getModuleByName("WEB"));

mgr->addModule(parallel);

SWMgr would then be smart enough to query the source type, which you'd 
return OSIS, and then it would add the, e.g., OSISRTF (for BibleCS) 
filters, when you call add the module to SWMgr.


Just throwing out ideas.

	-Troy.





Chris Little wrote:
> 
> 
> 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
> 
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page