In general, I think we all agree that standards should be used where
possible---a proliferation of APIs that our client software needs to
talk to leads to much harder to maintain client software than re-using
APIs.

However, if the standards are truly too hard to work with, sometimes the
'correct' decision is indeed to design a new one. However, I guess some
of our concern is that from observation, it kind of looks like the
OpenLibrary team didn't even consider SRU, it wasn't considered and
dismissed based on technical evaluation, but rather ignored from the
start. This is rather distressing, especially for a project with as
ambitious goals as OpenLibrary. For the project to be successful (which
most of us observers want very much), it's very important to understand
the existing technology landscape and how to fit into it.  Now, to be
sure, it may be that the existing _library_ technology landscape is not
particularly of interest to OpenLibrary, that they are more interested
in connecting with the larger technology world and see library
technology infrastructure as a tiny and irrelevant backwater. :)
That's up to them to decide this sort of strategy, and may be valid, and
would justify simply ignoring technology which is _mainly_ (but not
exclusively) adopted by the library world---but would of course be
distressing to us in the library technology world hoping we can connect
to the OpenLibrary project.

It's also nice to say "it's open source, if you want it you can add it."
And it DOES matter that it's open source, and this is HUGELY good. But
most of us are already working on multiple open source projects, many of
which _we_ are trying to recruit people too also.  It's a small pond of
library developers, and a big need for open source library software. If
OpenLibrary becomes as succesful as we all hope, then it will attract
open source contributions, from library developers and others. If the
OpenLibrary team wants to _get_ it to that succesful point, than in my
view it would be wise to spend OpenLibrary resources on components that
will make it easy for library and other developers to interface with it.
I'm sure they agree--which is why it has an API at all, rather than just
leaving it API-less and saying "hey, it's open source, if you want one
add one!".  That would obviously be counter-productive to the goals.

Again, I don't know enough about SRU to to know if it's suitable. I've
certainly encountered other library 'standards' that are over-engineered
and hard-to-adopt enough to justify abandoning them and creating
something new. All I'd hope is that the OpenLibrary team actually _knew
about_ SRU and gave it a serious evaluation---it is adopted enough to
justify that. It's also worth saying that when you DO abandon an
existing standard to write something new---it's a lot more productive to
building a sustainable tech infrastructure if you try to make your
'something new' at least a potential de facto standard, rather than a
custom thing only for your product.

Jonathan

Walker, David wrote:
>> Nobody in the *library world* uses
>> it, much less non-libraries.
>>
>
> Ironically, I was just checking email in between using the WorldCat SRU server.
>
> In addition to the systems Rob mentioned, there are also article databases like JSTOR and Springerlink that implement SRU, and every metasearch system in use in libraries today consume SRU web services.
>
> But I think the folks at OpenLibrary should implement an OpenSearch interface.  I mean come on!  OpenLibrary, OpenSearch.  A match made in heaven! ;-)
>
> --Dave
>
>
> -------------------
> David Walker
> Library Web Services Manager
> California State University
> http://xerxes.calstate.edu
>
> ________________________________
>
> From: Code for Libraries on behalf of Casey Durfee
> Sent: Wed 5/7/2008 1:12 PM
> To: [log in to unmask]
> Subject: Re: [CODE4LIB] Latest OpenLibrary.org release
>
>
>
> SRU is crap, in my opinion -- overengineered and under-thought,
> incomprehensible to non-librarians and burdened by the weight of history.
> The notion that it was designed to be used by all kinds of clients on all
> kinds of data is irrelevant in my book.  Nobody in the *library world* uses
> it, much less non-libraries.  APIs are for use.  You don't get any points
> for idealogical correctness.  A non-librarian could look at that API
> document, understand it all, and start working with it right away.  There is
> no way you can say that about SRU.
>
> Kudos to the OpenLibrary team, whatever the reason was, for coming up with
> something better that people outside the library world might actually be
> willing to use.
>
>
> On Wed, May 7, 2008 at 12:55 PM, Dr R. Sanderson <[log in to unmask]>
> wrote:
>
>
>> I'm the only non-techie on the team, so I don't know that much about
>>
>>> SRU.  (Our head programmer lives in India, and is presumably asleep at
>>> the moment, otherwise I'd ask him!)  Is it an interface that is used
>>> primarily by libraries?  We are definitely hoping that our API will be
>>> used by all kinds, so perhaps that's the reasoning.
>>>
>>>
>> It's designed to be used by all kinds of clients on all kinds of data,
>> but is from the library world so perhaps the most well defined use cases
>> are in this arena.  Have a look at:
>>  http://www.loc.gov/standards/sru/
>>
>>  But this is an Open Source project, so if anyone would like to volunteer
>>
>>> to build an SRU interface... you can!  Please do! :-)
>>>
>>>
>> I feel a student project coming on. :)
>>
>> Rob
>>
>>
>
>

--
Jonathan Rochkind
Digital Services Software Engineer
The Sheridan Libraries
Johns Hopkins University
410.516.8886
rochkind (at) jhu.edu