[sword-devel] Ruby GEM and Rails plugin for the Sword API

[Bill Burton]

Hello Nathan,

On 11/9/06, lumin8 <lumi.n8 at gmail.com> wrote:
>
>
> I was thinking of eventually creating a GEM so it could be easily
> > installed and used in any Ruby application.
> >
>
> Nice, I would be glad to help with a GEM and especially a Rails plugin.
> Would it be beneficial if I set up a SVN repository for this code?  Or maybe
> you have one available already for it.


Yes, SVN access would be fine.  If they can't create a branch on crosswire
for us (e.g. rubydl_binding) then you setting up something is fine with me.

I'll try to clean up the module and send it to you so you can start
> > experimenting with it.
>
>
Hopefully by late Saturday (EST).

Looking forward to it.   By the way, I was able to get Sword compiled, and
> did some looking around and experimenting with things.  I also found these
> two:
> Ruby/DL - http://ttsky.net/ruby/ruby-dl.html
> Ruby/DLX = http://ruby-dlx.rubyforge.org/index.xhtml
>
> Are you using one of these for the flatapi?


Yes, just the Ruby/DL that's included in the Ruby distribution.   If you
look in the modules for the "dl" folder, there's some examples and a doc
file.  It's also briefly mentioned in the Programming Ruby book in the
modules reference for "DL."

Ruby/DL can supposedly bind to C++ API's but then you have to deal with
mangled names.  I don't suppose those are portable between compilers so I
haven't gone in that direction.

-Bill

-=nathan
>
> On 11/8/06, Bill Burton <bburton at mail.com> wrote:
> >
> > Hello Nathan,
> >
> > On 11/8/06, lumin8 <lumi.n8 at gmail.com> wrote:
> > >
> > > 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.
> >
> >
> > I was thinking of eventually creating a GEM so it could be easily
> > installed and used in any Ruby application.
> >
> > 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.
> >
> > 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:
> > * Can't get a list of all the books in a Bible.
> > * Given a book name, can't get the number of chapters in the book.
> > * Given a book name and chapter, can't get the number of verses in that
> > chapter.
> >
> > If this information is available in the C++ classes, then it would be
> > worthwhile exposing in the C flatapi.
> >
> > 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.
> >
> > 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.
> >
> > Let me know if I can help with anything else.
> >
> >
> > I'll try to clean up the module and send it to you so you can start
> > experimenting with it.
> >
> > In His Service,
> > -Bill
> >
> > -=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.
> > > > >
> > > >
> > >
> >
> >
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.crosswire.org/pipermail/sword-devel/attachments/20061110/332bbbbc/attachment.html