Simon
Martin Gruner wrote:
Simon,
I maintain the API-docs for Sword, and they do contain a few class diagrams and such. Please checkout the sword-apidoc module from cvs.
Troy, can we have this on the website somewhere?
Martin
Am Samstag, 13. Dezember 2003 02:06 schrieb Simon Lagendijk:
Troy,
I'm really encouraged by your enthusiasm, but would really like
for you to cooperate in development with us. I'm not sure if you know
this or not, but your diagram could have names changes and be the
SWORD engine.
I wasn't aware of that. I searched the crosswire website for some diagrams, but couldn't find one. But if the Sword Engine does already contain a nice architecture, I can better spend my time in programming with the Sword Engine.
One question about the architecture of the Sword Engine: Does each module knows what it contains? In other words: if I have a bible module, does that module 'knows' which bible books it contains, and how much verses in each chapter? The reason I ask is because I don't want a fixed versification scheme, like that of the KJV, which makes it impossible to have the apocryphia or the book of mormon, or what else people want to add as an addiction to the canonical books (I am a protestant christian, so for me the apocryphia not that important, but there are people who consider them as holy). Another reason for wanting to have that information is to only show the biblebooks the module really contains. Can you please tell me if this problem exists, and what is planned to fix it?
We've even planned for some time to use OSIS as an intermediate
markup, like you describe below (currently, the route is src->dest but
would like it to be src->OSIS->dest, possibly: we're still hoping to
do a proof of principle to see the speed impact and repercussions).
Well, If nobody's working on it, maybe I can give it a try. The only problem is that I have to relearn C++ (last 4 years I've been working with Delphi and assembly, not much with C++), and get used to the wxWindows library and the Sword Engine, but I think that within a month I am as used to C++ as I am now to Delphi.
The text below is quoted from the mail which can be found at the above URL:The only difference, is that we didn't write a 'driver' to read flat OSIS files, not because it wouldn't be an easy plugin to the engine, but because of a number of other conscious decision defended in an email a few weeks back (about half-way down regarding XML +/-):
http://www.crosswire.org/pipermail/sword-devel/2003-November/019642.html
Plain, raw XML is not ideal, at least in my opinion, for our applications of working with data. It's an excellent archival and interchange format, but for realtime interaction and processing it has some of these problems:
o Many duplicated tokens (e.g. word level markup) that make file sizes huge, not catering to PDAs and other devices with storage limitations.
o Top down processing to know what 'level' and other 'context' you are within a document, which makes segmentation retrieval and display difficult.
It seems to me that using XML as a base document for your software will require many indices and other auxiliary files being build based on the document to allow fast retrieval and context hints. My conclusion would be that, it seems, if you are going to preprocess the document anyway, it might be best to use a compressed, or otherwise optimized format suited to your software needs. Preserving the original XML document doesn't seem to be beneficial.
Having said all of this, I just want to restate, we would LOVE to
colabor with you for our Lord! We definitely NEED someone to own the
OSIS import support and other XML processing tasks in the engine.
First, I don't share the idea that XML is only a interchange format. Indexes that contain Book-Chapter-Verse info are very easy to create, fast to access, and can be very small (using the right techniques). Secondly, I don't know if the Sword Engine has indexes for fulltext searches, but those can be created the same way for XML documents. Thirdly, I think supporting an well described format (like OSIS) with keeping the original file intact, instead of converting to a own module format, has some advantages. It makes the user more or less independant from the module making communitie, they can download an OSIS file, press the 'create indeces' button, and the document can be used Fourth, OSIS contains a lot of info about the text which is not saved in the module (correct me if I'm wrong). For example, take the CEV OSIS file, some verses are merged, it contains introductions, etc... Last, I want to write a script that automatically converts HTML/ThML/Text documents to OSIS. A friend of me is working on a program and website that can display and print OSIS files in a eastetic form. The idea behind it is that most theological documents on the internet have a very ugly layout (bold typeface, difficult to read background, unreadable font, etc). If that script is ready, tons of theological documents (mostly books) will be available in OSIS format. It would be nonsense if a user needs to wait until a OSIS text is converted to a module, before he can use it.
We could sure use your help. Please consider joining together
with us in this work.
I have considered, and you're totally right. Any restrictions that apply for code submitted to the Sword Project (besides that it has to be easy-to-read, and under GPL)? If there is a todo list (including priorities), please let me know...
Some last question: * Can the Sword Engine be compiled with MinGW? I don't have Borland C++ Builder or Visual C++, and prefer a free compiler (like MinGW) much above those commercial ones. * I noticed the Sword Engine uses a unicode library. In what way is that compatible with the wxString type of wxWindows?
In Christ,
Simon
_______________________________________________In Christ, -Troy.
PS. Blessings on your paper! PPS. OSIS 1.1.1 docs are available here: http://bibletechnologieswg.org/osis/docs/
Simon Lagendijk wrote:
Hi all,_______________________________________________
Thanks for your reply. Currently I'm using MinGW Studio for the programming, MinGW as compiler, and VisualWx for the form designing. It's does not work as well as, let say, Delphi, but its good enough to work with, and its free!
Development has stopped for this week because I've to write an essay for English class. As subject I choose 'ethics in a computer age', it's about the negative side of the computer age (about wasting time, unwanted temptations (porno), etc, and about how to deal with it). Very nice to see how, even on a non-christian school, lots of people admit the existence of those problems. If someone knows some good texts about this topic, please let me know....
Next week I hope to have a simplified OSIS reader ready, including a test app (console app). When thats finished, I'm going to work on the TagConversion (conversion of OSIS tags to HTML). When the HTML conversion is working, the GUI will be made (text showing will be done in a wxHTML control, so displaying text won't be to difficult). When that all is working, I'm going to implement the SWORD Engine. My idea is to support multiple 'reading engines', which are all independant from the original code, and all output OSIS, which will be converted to the format needed. Take a look at the attachment for an illustration of that idea.
PS> I do not want to offend anyone here by not just implementing the Sword Engine at the start, but I want first to have something wich is relatively simple working, and then add the more complex parts.
Simon
Simon,------------------------------------------------------------------------
I believe you earlier asked about cross-development compiler tools for Windows development?
If I understand your question (and if it was you that asked), there are several alternatives that I am aware of.
1. Al Stevens donated "Quincy" for free usage. It is a relatively simple ide that utilizes a gnu based compiler/linker back-end. It comes with several editions of his "Teach Yourself C++". The 2002 version comes with edition 7. It is mostly to facilitate building the sample code in his book. Kinda cool, but probably only adequate for early prototypes?
2. The Palm interface to the InVerse Scripture memorization freeware used the cgywin command line tools. It also uses gnu based compiler back-end. For me, I had to struggle to set it up, since I have little or no Linux experience. There may very well be an ide. My impression is that a very similar setup could be used for the development you have proposed, except some of the Palm specific files replaced. (someone else on this list probably is far more aware than I on this)
If you are interested and/or still need info, I can hunt around for links and directions.
HTH and sharing the reason for the season, http://learningcards.eeworks.org/EeCard01.html
Lynn A
_______________________________________________
sword-devel mailing list
[EMAIL PROTECTED]
http://www.crosswire.org/mailman/listinfo/sword-devel
sword-devel mailing list
[EMAIL PROTECTED]
http://www.crosswire.org/mailman/listinfo/sword-devel
sword-devel mailing list
[EMAIL PROTECTED]
http://www.crosswire.org/mailman/listinfo/sword-devel
_______________________________________________ sword-devel mailing list [EMAIL PROTECTED] http://www.crosswire.org/mailman/listinfo/sword-devel
_______________________________________________ sword-devel mailing list [EMAIL PROTECTED] http://www.crosswire.org/mailman/listinfo/sword-devel
