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