[sword-devel] Making Import Easier

[Greg Hellings]

DM and others involved in the import process --

I was just chatting with Matthew Talbert about the process of making
module import a much easier task than it is now.  Currently, most of
us are familiar with the process we go through when a new person tries
to make a module.  They often fall into one of a few categories: they
can't find the utilities because they're not packaged in their
distro's libsword package, they can't use a command line comfortable,
they have trouble finding the Windows build of the binaries, etc.

Obviously it's possible for the front-ends to have the ability to
create new modules and module content -- they do it with the Personal
commentary, and I believe that Xiphos even allows an arbitrary number
of personal commentaries to be created.  Wouldn't it be nice if it was
easy for a module to be created programmatically from a GUI interface?
 Why shouldn't a front-end have the ability to be pointed to a file on
the user's hard drive (or even remotely to a web-based resource or any
other number of resources) and have them press a button and voila!
their module appears (Handling the config file wouldn't be terribly
more difficult than any other form-based fill-in.  The frontend could
even have predefined values if the developers wanted, etc) in their
SWORD directories wherever they specify/have write permissions.

Implementing this should come for almost free with a minor change set
to the utilities/ directory.  Currently, AFAIK, most of the import
utilities are written in a single .cpp file per utility, which
includes a main() function.  If those utilities were refactored so
that the option handling and file reading was in one file and the
actual text processing and module writing were in a second file, that
would allow those second files to be included directly into the
library and be linked against by any front end.  The front end would
then be able to read the file from whatever source it wants (local,
web, ftp, gopher, ocr, whatever) and feed it into the same functions
that are used by the official import utilities.  Then any front end
who wants to play nice to the user like this would not have to
reduplicate the efforts of the current utilities, nor would they have
to hack the code out of the SWORD source and shoe horn it directly
into their own application.

Am I actually near the mark? Would this be something that could be
easily handled without being too much work (and, if it was handled,
would it be used by any of the front ends?)?  I think it would be a
very user-friendly thing to have available, but it would take work
from someone to refactor the utilities directory and also from the
front end developers to build support for this into their
applications.  I know I've been carrying the pumpkin for mod2osis for
most of the recent work on it, and would be happy to make these
changes to that program -- it wouldn't be the best one to include in
this effort, since there's lots of work it still needs to convert
non-OSIS original modules into its format well, but it's the only such
utility that I'm closely familiar with.

Thoughts, comments, accusations?

--Greg