[sword-devel] virtual modules

[Greg Hellings]

Is it necessary that the library utilize saved conf files for this
construct?  I really like the ability to dynamically swap modules in and
out, and that seems like it would require the creation of new .conf files
for every module combination that is desired.  It seems to me that the
number of parallel texts could rapidly expand out of hand in this way.  Just
presuming a basic install had some 10 modules installed, then that person
could have 10! module combinations if they don't repeat any, and an
unlimited combination if they repeat modules.  Numbers that grow
exponentially, especially if they are related to constrcuts in memory or on
disk, scare me.

I think providing the interface to a parallel module would be great, and
possibly allowing a .conf file to specify some predefined ones would be
useful, but I think that the most useful parallel construct would simply be
a dynamically accessible parallel module (with or without a limit to modules
viewable in parallel) which the front-end could swap in and out for
different module texts as well as add and remove them on-the-fly.  It might
be a little tricky to specify the interface for adding and removing texts,
especially if one text (such as the ASV) could be inserted multiple times to
get a parallel view of ASV-KJV-ASV-ALT-ASV-TR-etc.  But I think that would
be most useful... at least in my experience and thought.

--Greg


On 1/21/06, Troy A. Griffitts <scribe at crosswire.org> wrote:
>
> 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
>
> _______________________________________________
> 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
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.crosswire.org/pipermail/sword-devel/attachments/20060121/89703b77/attachment-0001.html