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

[Bill Burton]

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/20061108/6bf81d64/attachment.html