I guess I don't understand why you'd prefer SRU to an API.  The ideal
(in my mind) is that by having the API available, you have your cake
and eat it too.  Can a SRU (or OpenSearch or OpenURL or whatever)
service not be built on top of the API?

However, if there was no API available, only a SRU service, wouldn't
you complain about something else that SRU didn't do?

I don't know, personally I don't think it's the OL or IA's job to
build interfaces that they don't personally need.  I am much more
interested in them building functionality to the OL itself.  If a SRU
interface is important enough to somebody, they'll build one (or pay
IndexData to do it).

If the foundation is there, the standards can be built upon them.

-Ross.

On Thu, May 8, 2008 at 10:59 AM, Jonathan Rochkind <[log in to unmask]> wrote:
> 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
>