This will be a quick one because I’m feeling a bit under the weather, but I wanted to post a quick update on some of our tornado-like progress post-alpha.
A little history on JSON, etc.
I’m glad to see we’ve stirred the pot with our discussion of JSON. It’s driven us to stop and think about our decisions, their impact on our project, and how others may be able to interact with our system.
For the sake of those interested, I thought I might offer some clarity regarding our use of JSON. When OpenSRF (our core information passing framework, discussed here) was first designed, it was XML everywhere. As we were doing our benchmarking of the system, we thought things were good, but sluggish with large datasets. OpenSRF is designed as a set of independent applications which often must communicate with one or more other applications to accomplish any particular task. For example, to retrieve information on a patron, the system must verify the requesting party has such permission, then it must actually retrieve the information. With a lot of such conversation going on across the backbone, you can see there will be a great deal of data flying around the network.
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.