[OPEN-ILS-GENERAL] Comparison to Koha?

[Mike Rylander]

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