SPAM: Re: [OPEN-ILS-GENERAL] Comparison to Koha?

Sun Dec 31 14:45:08 EST 2006

Not even a Google search brought up any site that explained what 
OpenSRF was or what SRF stood for.  I did come across some 
interesting sites on Superconducting Radio Frequency activities and 
the Self Realization Fellowship, but somehow I doubt that these 
really have anything to do with OpenSRF.

Saying that OpenSRF is "a background mechanism allowing for seamless 
expandability in a cluster environment" does not really give someone 
like myself who is unfamiliar with it, enough knowledge to 
discriminate between the divergent understandings of OpenSRF that 
Mike and Josh seem to have.

If one of you could spare the time to give us non-programmer lurkers 
a more thorough explanation of OpenSRF--or at least point us to an 
existing explanation of the term, I would really appreciate it.

David

At 01:25 PM 12/31/2006, you wrote:
>On 12/31/06, Joshua M. Ferraro <jmf at liblime.com> wrote:
>>Hi all,
>>
>>Just catching up here ... I'll just clarify a few points on the Koha end:
>>
>>----- Don McMorris <don.mcmorris at gmail.com> wrote:
>
>[snip]
>
>> > In the early stages of Evergreen, the developers' made OpenSRF, a
>> > background mechanism allowing for seamless expandability in a cluster
>> > environment.  (I believe) Koha is made to run on a single server,
>> > thus having limited capacity.
>>Actually, not quite right here. We've been running multi-server Koha
>>installations when OpenSRF was still an idea (I remember some of those early
>>conversations about OpenSRF in the early planning phase ;-). The underlying
>
>While many applications respond well to load balancing (as I imagine
>Koha would, assuming MySQL didn't become a bottleneck), that's not the
>same as what OpenSRF does.  Obviously, it provides load balancing, but
>that is only one benefit of the design.
>
>Now seems like as good a time as any to try giving a better
>explanation of OpenSRF, or reasons for it's existence if not more
>technical details.  So...
>
>A little clarification by way of history:  OpenSRF (pre-name) was
>basically the first thing we worked on after getting our bearings, and
>Bill and I did this over the course of a month or so in early fall
>2004.  We had the OpenSRF design and initial implementation before
>there were any public discussions, AFAIR, not to mention long before
>we were active in #code4lib (though we probably had been lurking).
>It's first mentioned here[1] and later got its name here[2].  While
>the latter post has a pretty explicit (and aggressive) time line, we
>found that the majority of things on the OpenSRF todo list weren't
>really needed in our environment, so many have gone unimplemented.
>I'd love to pick those back up (OpenSRF being my favorite technical
>bit of the Evergreen project) but I don't know where I'll ever find
>the correctly shaped tuits... :(
>
>Application session management, infrastructure for transactional
>semantics (something simple load balanced web apps normally can't or
>don't do), geographical redundancy and distribution, targeted
>clustering, client and server programming language agnostic services
>(Perl, C, Python (RSN) and JavaScript today, in addition to a REST-ish
>XML gateway and XMLRPC interface provided by the OpenILS code) --
>these are some of the things you get for free with OpenSRF.
>
>OpenSRF is built such that the overhead of adding more servers scales
>at a worst case of O(N) for N servers, and transaction overhead scales
>at a worst case of O(2N) for N transactions.  With good hashing
>algorithms in the Router and the jabber server (which we seem to have
>...) and a fast network, the server scaling looks more like O(1) and
>the transaction scaling O(N).  All while retaining transparent
>clustering, session management, security infrastructure, etc.
>
>OpenSRF's not meant just to power a web interface, it's meant to build
>networks of applications with low overhead (development /and/ run
>time) and high up time and scalability, both vertical and horizontal.
>The http interface and load balancing are actually very small parts of
>the overall OpenSRF system and design.  In short, OpenSRF is a
>platform for creating and integrating applications, more in in the
>vein of CORBA or JNI than, say, HTML::Template or RoR (for instance).
>
>[1] http://open-ils.org/blog/?p=11
>[2] http://open-ils.org/blog/?p=21
>
>>In terms of internationalization support, AFAIK, EG doesn't currently
>>have any :-).
>
>This is not the first time I've seen that claim on this list ... and
>I'm frankly not sure where the idea comes from because it's simply not
>true.  Evergreen has had I18N infrastructure since day one.
>
>What /is/ true is that EG does not have _translations_ for languages
>other than English.  We'd love to have translation contributions, and
>all it takes is creating a translation of the entities in these*
>files.  The files I see being used the most (just a quick grep on the
>cvs tree) are opac.dtd (for the OPAC... surprise!) and lang.dtd (for
>the staff client).  The other may be used, but Bill and Jason will
>need to jump in to clarify them.
>
>* http://open-ils.org/cgi-bin/viewcvs.cgi/ILS/Open-ILS/web/opac/locale/en-US/
>
>> > Because of Evergreen's scalability and rigorous compliance to very
>> > complex standards, there may be more administrative overhead than vs.
>> > the somewhat simpler Koha.  Koha, as I recall, is mostly scripts and
>> > MySQL.  Evergreen is pretty complex in that it involves several perl
>> > dependencies, specialized Apache configuration, Jabber, and various
>> > other things.  This may make troubleshooting more difficult in
>> > Evergreen vs. Koha.
>>I'm not sure which standards you're referring to, but Koha complies to
>
>I believe Don was referring to the late entrance of MARC support in
>Koha, according to press reports.  While that doesn't necessarily mean
>anything with regard to the current Koha code, it does suggest an
>evolution toward standards.  In no way a bad thing, but a difference
>nonetheless.
>
>--
>Mike Rylander
>mrylander at gmail.com
>GPLS -- PINES Development
>Database Developer
>http://open-ils.org
>

David Dorman
US Marketing Manager, Index Data
52 Whitman Ave.
West Hartford, Connecticut  06107
dorman at indexdata.com
860-389-1568 or toll free 866-489-1568
fax: 860-561-5613

INDEX DATA Means Business
for Open Source and Open Standards
- - - - - - - - - - - - - - -
www.indexdata.com