Hello Nathan,<br><br><div><span class="gmail_quote">On 11/8/06, <b class="gmail_sendername">lumin8</b> <<a href="mailto:lumi.n8@gmail.com">lumi.n8@gmail.com</a>> wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
Bill,<br><br>Yes exactly. Sounds like you are doing some great work with this.<br>I'm trying to figure out how I can help - at the least I could package<br>it as a rails plugin or gem making it easy for any ruby on rails
<br>developer to get started with it.</blockquote><div><br>I was thinking of eventually creating a GEM so it could be easily installed and used in any Ruby application. <br><br>However, I think a Rails plug-in would be a good idea to provide any extra support that makes sense specific to a Rails application. At the very least, providing a default controller implementation and/or helper methods that could be used in other controllers would be worthwhile. The ActionService web service client support might be a good pattern to start with.
<br><br>Also, right now, there's a limitation with the Sword C flatapi API in that there's limited metadata available for Bible modules. What I mean is you:<br>* Can't get a list of all the books in a Bible.<br>* Given a book name, can't get the number of chapters in the book.
<br>* Given a book name and chapter, can't get the number of verses in that chapter.<br><br>If this information is available in the C++ classes, then it would be worthwhile exposing in the C flatapi.<br><br>So in the meantime, an application using the C flatapi has to provide it's own support to maintain this metadata. As versifications are different in some translations, you can't necessarily use the same information for all translations.
<br><br>In regards to creating a unique key to represent a Bible verse, it may be helpful to create a utility class like VerseKey that can take any verse reference with a variety of abbreviations and return it in OSIS notation.
<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">Let me know if I can help with anything else.</blockquote><div><br>I'll try to clean up the module and send it to you so you can start experimenting with it.
<br><br>In His Service,<br>-Bill<br></div><br><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">-=nathan<br><br><br>On 11/7/06, Bill Burton <
<a href="mailto:bburton@mail.com">bburton@mail.com</a>> wrote:<br>> Hello,<br>><br>> I see. You want the module information in a database because it's then<br>> trivial to program a web application using Ruby on Rails ActiveRecord object
<br>> relational mapping support. RoR also supports other logic in controllers<br>> such as web services clients so it's entirely possible to write an<br>> application that calls Sword without using a database but the scaffolding
<br>> code generator won't be able to help much if at all.<br>><br>> It just so happens I've been working on a Ruby interface to Sword with a<br>> longer term goal of writing a Ruby on Rails application to access it.
<br>> Initially, I couldn't figure out how to build anything with SWIG--there's no<br>> README in the bindings/swig directory. Then it happened I discovered Ruby<br>> can load shared libraries and DLL's and dynamically bind to them on the fly
<br>> using the dynamic loader (DL) module. So I started to write a Sword<br>> interface to the C flatapi in bindings/flatapi.cpp. In the process, I found<br>> a few minor bugs with the flatapi but have created patches to fix them
<br>> (which I'll submit soon).<br>><br>> Using this Ruby to Sword flatapi interface you can output verses as follows<br>> (I'm doing this from memory so it's not exact):<br>><br>> include Sword<br>> # SWMgr_new(FMT_HTML)
<br>> Manager.new (Sword::FMT_HTML) do |mgr|<br>> module = mgr.get_module("KJV")<br>> # iteration using Sword API's under the covers to verseKey and renderText<br>> module.each_verse_render("Psalm 133:1-3") do |verse, text|
<br>> puts "#{verse} #{text}" # verse reference and text<br>> end<br>> end # performs an implicit SWMgr_delete<br>><br>> So far, I've implemented about two-thirds of the Sword C flatapi. However,
<br>> the one issue I'm just starting to address is how to call these API's within<br>> a multi-threaded multi-user environment such as a web application. Because<br>> the SWMgr_new/newEx and SWModule_* functions have state, it looks like a new
<br>> Manager object will have to be created per user which means establishing a<br>> session and then saving the Manager instance in the session. So I have to<br>> refactor the code to allow multiple instances of a Manager class without
<br>> loading the shared library every time.<br>><br>> But then last night I was about to send an email to this list asking how to<br>> build the SWIG interface but I looked at it one more time and discovered how
<br>> to do it. With some more investigation I was then able to generate SWIG<br>> bindings for Ruby and build the interface to Sword. So far I've been able<br>> to access some of the methods from the SWMgr and SWModule classes but can't
<br>> output a verse because the binding of set_key to SWModule.SetKey is<br>> incorrect. This may be a bug in the way SWIG generated the binding but I<br>> don't know yet.<br>><br>> The nice thing about the Ruby dynamic loader interface to Sword is there's
<br>> nothing extra to build which makes it much easier to install as compared<br>> with the SWIG version. However, the C flatapi on which it's based limits<br>> one to getting and setting global options, iterating over modules and
<br>> rendering verses. The SWIG interface to the C++ API's is much more complete<br>> but has to be built. I don't know yet if the Sword C++ API's also have state<br>> which is important to know for a web application.
<br>><br>> Right now, I'm developing on RedHat ES 3 but plan to test the DL version on<br>> Windows against an installed BibleCS. My time is limited but I'll try to<br>> get this binding in reasonable shape soon so it can be used with Ruby on
<br>> Rails. Building the SWIG version on Windows is not an option for me at this<br>> time due to lack of tools and a dead machine.<br>><br>> God is merciful,<br>> -Bill<br>><br>> On 11/7/06, lumin8 <
<a href="mailto:lumi.n8@gmail.com">lumi.n8@gmail.com</a>> wrote:<br>> ><br>> > > I'll leave the question alone as to the value of a relational database<br>> > > for this data over using the SWORD API.
<br>> ><br>> ><br>> > Actually, I am interested in this question if you have time / desire to<br>> enlighten me. I think I can manage the chunk of code you gave me (thanks),<br>> but I have never compiled a program in my life. I have been building web
<br>> applications for about 7 years with PHP, and now Ruby for the last year and<br>> a half.<br>> ><br>> > I am willing to learn the Sword API if I need to, but I can build web<br>> applications very quickly with Ruby on Rails. The rest of my data (user
<br>> info, notes, user generated translations, a wiki like interface for<br>> commentary) will all be in a relational database. Would there be speed<br>> benefits from using the Sword API over the indexing provided by mysql or
<br>> postgre? What about application development time? In the Rails framework,<br>> I hardly even have to write SQL, if I used the Sword API I would have to<br>> learn a bit about c++ and bindings to Ruby... I am willing, but what is the
<br>> advantage?<br>> ><br>> > By the way, I have tried and use many of the Sword front ends and highly<br>> respect the work you all are doing.<br>> ><br>><br></blockquote></div>