Tim McGeary wrote:
> have access to that API. I brought this up at the code4lib conference:
> our vendor already gives us these APIs in some way or another, and we
> have to agree not to give our API apps even to other libraries who
> haven't signed on for API certification.
This is the biggest problem right there. Some vendors make you agree not
to give your API apps to _anyone_, even other customers who have signed
the same NDA's and have the same certifications! This is the big problem
right there.
If it wasn't for that, a really realistic path I would see is this:
People like Tim write software based on what APIs the vendor already
gives them (and/or direct database access if neccesary and possible),
and this software then in turn _provides_ DLF-compatible APIs. That is,
we, the libraries who already have to hack these proprietary APIs anyway
and are already spending time doing it, write adaptors from the
proprietary stuff that exists, to a common set of APIs. We're willing
to spend the time because we get the gain.
But in order to do this, our vendors need to give us _some_ way into the
data so we can write these adaptors. Most but not all of our vendors
already give us this technical ability, in one way or another. But our
contractual agreements prevent us from actually _doing_ it! Writing an
adaptor we're not allowed to share with anyone is no good.
So it's on that legal/contractual front, not the technical front, that I
see as _currently_ the biggest barrier to success here, and it's there
that we and DLF should be putting our effort.
Jonathan
Received on Thu Apr 17 2008 - 14:03:46 EDT