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 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 > > The text below is quoted from the mail which can be found at the above URL: > > 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
