[From nobody Mon Aug 14 10:25:05 2006 Message-ID: <44DEABE4.3040400@crosswire.org> Date: Sat, 12 Aug 2006 21:34:44 -0700 From: "Troy A. Griffitts" <scribe@crosswire.org> User-Agent: Thunderbird 1.5.0.4 (X11/20060614) MIME-Version: 1.0 To: Martin Gruner <mg.pub@gmx.net> Subject: Re: looking ahead / Prayer Requests References: <200607311927.12482.mg.pub@gmx.net> In-Reply-To: <200607311927.12482.mg.pub@gmx.net> Content-Type: text/plain; charset=UTF-8; format=flowed Content-Transfer-Encoding: 7bit X-UID: 12923 X-Keywords: Hey Martin, It's always good to re-evaluate our vision and direction, so thanks for giving me the opportunity to write some thoughts. > since we don't seem to meet in IRC.... You sleep too early. :) > How are you doing these days? Do you work for school, job, any news? We just > got a new (used, 3 yrs) car (Renault Megane), and it rocks =). Awesome! Congratulations! My old '94 Celica is still running ok. It's paid for, so I'm happy with it while it still runs! > DM said he expects a new Sword CD to be released soon. Is that true? Yeah, we have a number of outstanding CD orders that I need to fill, so I told him my plan to cut a new CD with the the latest BibleCS once we release. We really need to have a group meeting about the CD layout. I have never been happy with binary distribution on linux. I'd like for us to discuss ideas of how best to distribute our products on CD. > I've got a couple questions regarding Sword: What do you expect for the > development of Sword (the C++ lib) and its module library in the next years? ... > What features do you want to > be implemented and when do you expect that to happen? (I've learned that 'when' in volunteer opensource development is not an intelligible concept) Here are my 'whats'... Completion of VerseTreeKey class to support exposing a genbook as a Bible. zGenBook Expanded support for references. Currently sword support only generic (not tied to a specific module) Bible references. Additional support for generic references of any type (Bible.KJV:John.3.16, Person:Paul.of.Tarsus, Strongs:G1591). Additional support for references to a specific sword module name (Bible.KJV@KJV2003:John.3.16). Which might fall back to another module if the user didn't have the specific module installed. Mapping system between reference systems (Bible.KJV <--> Bible.LXX).. Martin, you've done some good work recently to consolidating these reference systems. I've been meaning to talk with you about your recent work. I had planned to suggest that we might try using code like: RawLD::createModule("Scheme1ToScheme2"); RawLD *mod = new RawLD(modname); for (...) { mod->setKey(fromOSISid); mod->setEntry(toOSISid); } So we might not introduce a new dependency of sqlite. Possibly some way to trigger lucene index fields to be created with a new filter classification. This would modularize field creation so new search fields could be added simply by adding a new filter. Currently we have 4 fields that are hardcoded in the creation index creation code. It would be nice to split these 4 up into small, selfcontained filters which generate their field text, so the index create code doesn't have to know about any of this stuff, and we could add a new one without having to know all the details of the index creation code. Finally, the roadmap in jira is still valid. I'd like to do a 2.0 release soon that has the API interface normalized. It's gotten pretty inconsistent over the 15 years of coding. > Do you see any changes to the development model? What development model? :) I've pretty much conceded to the fact the we are like all other opensource projects. There is a very small group of people who do all the work, and everyone else just complains. There is no solution. Actually, what HAS worked really well for us is people OWNING small components of the project. I like the fact that you've taken ownership of our Hebrew support (though I was going to chide you about using <br> in the .conf of the WLC :) ). People own all kinds of subprojects like Bibletime, Gnomesword, JSword, MacSword, etc. That seems to work out great. Like, for example, Daniel owned our autotools build system for a long time. What a great blessing! He hounded me forever to switch, and persisted even when I refused to switch until the autotools build system allowed the same functionality and options as the previous hacked makefile system. He owned it, developed it over time, and sword would never be accepted in so many distros had it not been for his work. I still have next to no clue how autotools works :) (side note: He's been really busy with other things lately and I've been wanting our build system to be able to build a debug version WITHOUT optimization, for a long time (there is a jira bug report). Debugging is pretty much useless when optimization is turned on. I added a silly debug.sh script which finds all makefiles and changes -O2 to -O0 so I can effectively debug. It's a longstanding issue and I am not an expert at autotools). I don't want to become an expert at autotools. I'd like for Daniel-- or if he cannot commit the time any longer, for more pressing service elsewhere, them someone else-- to own that component. Chris has owned our unicode support for quite some time. I remember sitting with him about 4 years back in San Francisco researching how UTF8 worked and writing some prototype filters together. It was a blast. But he's taken that stuff and expanded it and maintains it, and I've hardly looked at it since then; same with ICU, except I didn't help at all on that stuff. The bindings stuff is owned by... er, I'm not even sure these days! But people are updating them. We need to get them access to the bindings directory in the repository so they can maintain stuff as they like. So, I guess, OWNERSHIP is the key word. I'd like to encourage people to commit to own, maintain, and expand an area where they are interested and feel led to commit part of their life. I realize our lives are important and we need to consider how we spend the short time that God gives us here. We have many orphaned projects that need owners: SwordReader (CE Version), QPSword (Qtopia/OPIE version)-- though Dagger sounds like it is being regularly updated, which is nice, and others. > > I'd really appreciate to read your opinions and visions for the nearer and > farer future of Sword. This is no attempt to change, just to learn. =) Thanks Martin. I'm still looking forward to finishing up this stuff, normalizing the API calls, and then start on some real research work. I'm really excited about using the engine to produce some cool next generation tools-- one of which is a facility for a scholarly online community where they can do textual research and contribute their expert knowledge toward an open repository of data anyone can download and use for research. I see a line coming up soon where my hope is that we can cross from focusing on features to the engine, to instead focus on both better content and new tools which use the engine. I hope this gives you an idea of where my heart desires to lead efforts at CrossWire. Our purpose statement remains steadfast, to be a resource to Bible Societies and other ministry organizations by giving them technical tools and skilled time to help them reach their domain with Christ. I personally have a desire to facilitate scholarly communities and believe this will help domain experts and scholars at these organizations collaborate and foster the next generation of content for ministry in an ever more data-centric society. My prayer request this week is that we would all have a complimentary vision for serving our Lord-- not identical, necessarily, just complimentary. Oh, and I have a 12 page paper to write to finish my summer course, which is due Monday at 10am. :) This is alot to read for a prayer request, so I trust you'll stick it at the end or someplace that doesn't disrupt the flow of our usual prayer time. Thanks again, Martin. Looking forward to praying with you all. -Troy. > May God bless you. > > mg ]