This month, as you might imagine, has been dominated by work on the upcoming cataloging-staff client demo release. We’re progressing smoothly and steadily, and expect to reach our target release date of March 18th. Allow me to reiterate some of the features that we expect to have available in this upcoming demonstration release:
The birth of OpenSRF
After months of work, buckets of sweat, and one snapshot of code seemingly unrelated to libraries, we are proud to present our first subproject: OpenSRF (Open Scalable Request Framework), pronounced “open surf”. The 0.1 release of OpenSRF represents the culmination of everything we have posted about here, and some things we haven’t.
One of the main differences between our initial snapshot tarball and the shiny new OpenSRF code is the removal of the dependence on an Auth Application. We have decided that the security provided by Jabber is sufficient for connection to the OpenSRF network, and application level authentication and authorization should be handled either by each individual Application, or by an Authentication Application built specifically for the target problem domain.
The Router : More on Communication
We’ve recently completed version 0.1 of what we call, simply, “The Router”. Someday a different loving name will likely fall from the sky, but until then…
The Router is more accurately described as a Jabber Request Load Balancer and Message Router/Broadcaster. Our main use is to employ The Router balancing client requests across a redundant array of application servers. Now take that idea and multiply it across a set of routers (probably one per Jabber server or Jabber domain) and you have a Jabber communication web that’s intelligent enough to recover from the loss of any single node (jabber server, Router, application server).