Quoting Matthew Talbert <[EMAIL PROTECTED]>: > > I am a programmer, but I shudder at the thought of digging through all > of the engine code, plus various front-end code, just to determine how > to encode a module. After this discussion, I am less convinced than > ever that I should even attempt an OSIS module. >
On the other hand, I am a programmer, but as a frontend (filter) developer I shudder at the thought of digging through all of the engine code and full OSIS/Thml/other documentation to determine how to write a filter to represent a module. The answer to this problem is the same than in module writer's case: good brief documentation of Sword OSIS conventions. Module developers should never be forced to read programming language source code. Programmers may be more able to read module code etc. but we all seem to have one problem in common: time. I don't have time for BibleTime, engine and modules. BibleTime is my preference at least ATM. Better documentation would help a lot. It's not too difficult to enhance OSIS or TEI etc. support but I just can't start thinking about TEI if I have to google and read dozens of pages guessing what's relevant and what's not. Or for OSIS, test dozens of modules from beginning to end and try to find if there are some features which are not supported. Good module support is very important to me and I can do the programming but I just can't find all use cases. BTW, I have read the "official" OSIS documentation but it's far from perfect and many definitions are vague. Our Wiki documentation is a good start but can't be used for frontend development without other docs. --Eeli Kaikkonen _______________________________________________ sword-devel mailing list: [email protected] http://www.crosswire.org/mailman/listinfo/sword-devel Instructions to unsubscribe/change your settings at above page
