Hello,<br><br>I see.&nbsp; You want the module information in a database because it's then trivial to program a web application using Ruby on Rails ActiveRecord object relational mapping support.&nbsp; RoR also supports other logic in controllers such as web services clients so it's entirely possible to write an application that calls Sword without using a database but the scaffolding 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 longer term goal of writing a Ruby on Rails application to access it.&nbsp; Initially, I couldn't figure out how to build anything with SWIG--there's no README in the bindings/swig directory.&nbsp; Then it happened I discovered Ruby can load shared libraries and DLL's and dynamically bind to them on the fly using the dynamic loader (DL) module.&nbsp; So I started to write a Sword interface to the C flatapi in bindings/flatapi.cpp.&nbsp; In the process, I found a few minor bugs with the flatapi but have created patches to fix them (which I'll submit soon).
<br><br>Using this Ruby to Sword flatapi interface you can output verses as follows (I'm doing this from memory so it's not exact):<br><br><div style="margin-left: 40px;">include Sword<br># SWMgr_new(FMT_HTML)<br>Manager.new
(Sword::FMT_HTML) do |mgr|<br><div style="margin-left: 40px;">module = mgr.get_module(&quot;KJV&quot;)<br># iteration using Sword API's under the covers to verseKey and renderText<br>module.each_verse_render(&quot;Psalm 133:1-3&quot;) do |verse, text|
<br><div style="margin-left: 40px;">puts &quot;#{verse} #{text}&quot;&nbsp; # verse reference and text<br></div>end<br></div>end&nbsp; # performs an implicit SWMgr_delete<br></div><br>So far, I've implemented about two-thirds of the Sword C flatapi.&nbsp; However, the one issue I'm just starting to address is how to call these API's within a multi-threaded multi-user environment such as a web application.&nbsp; Because the SWMgr_new/newEx and SWModule_* functions have state, it looks like a new Manager object will have to be created per user which means establishing a session and then saving the Manager instance in the session.&nbsp; So I have to refactor the code to allow multiple instances of a Manager class without 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 build the SWIG interface but I looked at it one more time and discovered how to do it. With some more investigation I was then able to generate SWIG bindings for Ruby and build the interface to Sword.&nbsp; So far I've been able to access some of the methods from the SWMgr and SWModule classes but can't output a verse because the binding of set_key to 
SWModule.SetKey is incorrect.&nbsp; This may be a bug in the way SWIG generated the binding but I don't know yet.<br><br>The nice thing about the Ruby dynamic loader interface to Sword is there's nothing extra to build which makes it much easier to install as compared with the SWIG version.&nbsp; However, the C flatapi on which it's based limits one to getting and setting global options, iterating over modules and rendering verses.&nbsp; The SWIG interface to the C++ API's is much more complete but has to be built. I don't know yet if the Sword C++ API's also have state 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 Windows against an installed BibleCS.&nbsp; My time is limited but I'll try to get this binding in reasonable shape soon so it can be used with Ruby on Rails.&nbsp; Building the SWIG version on Windows is not an option for me at this time due to lack of tools and a dead machine.
<br><br>God is merciful,<br>-Bill<br><br><div><span class="gmail_quote">On 11/7/06, <b class="gmail_sendername">lumin8</b> &lt;<a href="mailto:lumi.n8@gmail.com">lumi.n8@gmail.com</a>&gt; wrote:</span><blockquote class="gmail_quote" style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;">
<span class="q"><blockquote style="border-left: 1px solid rgb(204, 204, 204); margin: 0pt 0pt 0pt 0.8ex; padding-left: 1ex;" class="gmail_quote">I'll leave the question alone as to the value of a relational database<br>for this data over using the SWORD API.
</blockquote></span><div><br>Actually, I am interested in this question if you have time / desire to enlighten me.&nbsp; I think I can manage the chunk of code you gave me (thanks), but I have never compiled a program in my life.&nbsp; I have been building web applications for about 7 years with PHP, and now Ruby for the last year and a half.
<br><br>I am willing to learn the Sword API if I need to, but I can build web applications very quickly with Ruby on Rails.&nbsp;&nbsp; The rest of my data (user info, notes, user generated translations, a wiki like interface for commentary) will all be in a relational database.&nbsp; Would there be speed benefits from using the Sword API over the indexing provided by mysql or postgre?&nbsp; What about application development time?&nbsp; In the Rails framework, I hardly even have to write SQL, if I used the Sword API I would have to learn a bit about c++ and bindings to Ruby...&nbsp; I am willing, but what is the advantage?
<br><br>By the way, I have tried and use many of the Sword front ends and highly respect the work you all are doing.<br></div>


</blockquote></div><br>