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

Sun Dec 31 16:26:24 EST 2006

On 12/31/06, David Dorman <dorman at indexdata.com> wrote:
> Not even a Google search brought up any site that explained what
> OpenSRF was or what SRF stood for.  I did come across some

The SRF stands for Service Request Framework.

Re google searching, http://www.google.com/search?q=opensrf gave me
some good results, though there were many CPAN generated test pages.
Seeing that, I tried http://www.google.com/search?q=opensrf+-bundle
which seemed useful.

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

Heh ... yeah, no relation.  :)

> Saying that OpenSRF is "a background mechanism allowing for seamless
> expandability in a cluster environment" does not really give someone

I think those were Don's words ...  your point, however, remains.  My
previous response (what you responded to) was in part an attempt to
clarify what OpenSRF is in a general sense:

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

I guess judgment at to whether I succeeded in giving an idea of what
OpenSRF is should be left as an exercise for any more responders...
though I admit it's not looking good.  :)

> like myself who is unfamiliar with it, enough knowledge to
> discriminate between the divergent understandings of OpenSRF that
> Mike and Josh seem to have.

Well, I can say unequivocally as co-author and designer of the
software (Bill Erickson and myself are the only ones that have written
any OpenSRF code), I do actually understand it -- in other words, Bill
and I are _the_ authoritative sources for OpenSRF "understanding"
today.  Hopefully as others dig into the code that will change, but
for now if anyone has questions about OpenSRF they can expect Bill's
and my answers to be the most well-informed.

Having said that, OpenSRF is just a tool, and unless one knows how to
leverage the strengths of this particular tool then it could be seen
as merely a load balancing device.

We've written many blog posts about it, some describing how it works
and some showing how to build an application using it.  There is also
(some) documentation on the wiki.  Good resources to start learning
about the details of the system are:

http://open-ils.org/blog/?cat=4 -- blog entries in the OpenSRF
category.  I've updated some older pre-category posts to make them
easier to find.

http://www.slideshare.net/eby/evergreen-future-of-the-ils/ -- slides
from a recent presentation.  OpenSRF stuff starts around slide 22.

http://open-ils.org/dokuwiki/doku.php?id=osrf-devel:user_s_guide --
skeleton of some OpenSRF docs.  See appendix D, linked near the
bottom, for an explanation of terminology.

And, for those so inclined, there's always the UTSL method.  :)

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

More documentation would be helpful, I agree.  Any technical writers
in the crowd? ;-)

-miker

(PS: Please try to avoid top-posting.  It makes it harder to follow
along inside the context of the conversation.  Thanks!)

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

-- 
Mike Rylander
mrylander at gmail.com
GPLS -- PINES Development
Database Developer
http://open-ils.org