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