[sword-devel] modules to relational database (Ruby support)

[lumin8]

Bill,

Yes exactly.  Sounds like you are doing some great work with this.
I'm trying to figure out how I can help - at the least I could package
it as a rails plugin or gem making it easy for any ruby on rails
developer to get started with it.

Let me know if I can help with anything else.

-=nathan


On 11/7/06, Bill Burton <bburton at mail.com> wrote:
> Hello,
>
> I see.  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.  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.
>
> 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.
> Initially, I couldn't figure out how to build anything with SWIG--there's no
> README in the bindings/swig directory.  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.  So I started to write a Sword
> interface to the C flatapi in bindings/flatapi.cpp.  In the process, I found
> a few minor bugs with the flatapi but have created patches to fix them
> (which I'll submit soon).
>
> Using this Ruby to Sword flatapi interface you can output verses as follows
> (I'm doing this from memory so it's not exact):
>
> include Sword
> # SWMgr_new(FMT_HTML)
> Manager.new (Sword::FMT_HTML) do |mgr|
> module = mgr.get_module("KJV")
> # iteration using Sword API's under the covers to verseKey and renderText
> module.each_verse_render("Psalm 133:1-3") do |verse, text|
> puts "#{verse} #{text}"  # verse reference and text
> end
> end  # performs an implicit SWMgr_delete
>
> So far, I've implemented about two-thirds of the Sword C flatapi.  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.  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.  So I have to
> refactor the code to allow multiple instances of a Manager class without
> loading the shared library every time.
>
> 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.  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.  This may be a bug in the way SWIG generated the binding but I
> don't know yet.
>
> 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.  However, the C flatapi on which it's based limits
> one to getting and setting global options, iterating over modules and
> rendering verses.  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.
>
> Right now, I'm developing on RedHat ES 3 but plan to test the DL version on
> Windows against an installed BibleCS.  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.  Building the SWIG version on Windows is not an option for me at this
> time due to lack of tools and a dead machine.
>
> God is merciful,
> -Bill
>
> On 11/7/06, lumin8 <lumi.n8 at gmail.com> wrote:
> >
> > > I'll leave the question alone as to the value of a relational database
> > > for this data over using the SWORD API.
> >
> >
> > Actually, I am interested in this question if you have time / desire to
> enlighten me.  I think I can manage the chunk of code you gave me (thanks),
> but I have never compiled a program in my life.  I have been building web
> applications for about 7 years with PHP, and now Ruby for the last year and
> a half.
> >
> > I am willing to learn the Sword API if I need to, but I can build web
> applications very quickly with Ruby on Rails.   The rest of my data (user
> info, notes, user generated translations, a wiki like interface for
> commentary) will all be in a relational database.  Would there be speed
> benefits from using the Sword API over the indexing provided by mysql or
> postgre?  What about application development time?  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...  I am willing, but what is the
> advantage?
> >
> > By the way, I have tried and use many of the Sword front ends and highly
> respect the work you all are doing.
> >
>
>
> _______________________________________________
> sword-devel mailing list: sword-devel at crosswire.org
> http://www.crosswire.org/mailman/listinfo/sword-devel
> Instructions to unsubscribe/change your settings at above page
>
>


-- 
_______________________________

portland, or: 01 (503) 608-7950
cuernavaca, mx: 52 (777) 318-9094