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

[lumin8]

> 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.


Does anyone else on this list know the answer to this question?  Also, where
is the documentation for the Sword API - what are the features?  I must be
overlooking something.

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.

I'll try to clean up the module and send it to you so you can start
> experimenting with it.


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?

-=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.
> > > >
> > >
> >
>
> _______________________________________________
> 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
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://www.crosswire.org/pipermail/sword-devel/attachments/20061109/6b6c1d12/attachment.html