[OPEN-ILS-GENERAL] [OPEN-ILS-DEV] Evergreen API

[Lori Bowen Ayre]

Thanks, All.  I know we don't need APIs in the same sense that a
proprietary system does.  However, I've spoken to some developers of other
products who are interested in integrating their product with Evergreen and
I keep hearing that this is very challenging because it isn't clear what
does what and how to do that without making a pretty big investment in
learning Evergreen internals.

I'm just looking for a way to lower the barrier for outside developers who
have something we might want to use with Evergreen, how can we make it
easier for them to work with our product?

Lori

=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-==-=-=-=-=-=-=-=-=
Lori Bowen Ayre //
Library Technology Consultant / The Galecia Group
Oversight Board & Communications Committee / Evergreen
(707) 763-6869 // Lori.Ayre at galecia.com
Availability:  http://tungle.me/lori.ayre

<Lori.Ayre at galecia.com>Specializing in open source ILS solutions, RFID,
filtering,
workflow optimization, and materials handling
=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=-=



On Mon, May 14, 2012 at 6:05 AM, <rogan.hamby at yclibrary.net> wrote:

>
> To echo Dan, and without reading ahead to the weekend's posts, developers
> usually talk about APIs in terms of methods of accessing the functions of a
> system.  Usually, the APIs are bundled and published because the core
> system is closed in some way or licensing is involved.  If you want a
> fascinating discussion right now about what APIs really are the Google /
> Oracle lawsuit has brought a lot of great information into the open about
> what people agree APIs are and what they disagree about them being and the
> legal grey area of them.
>
> Anyway, that aside Evergreen is very open and doesn't really need APIs in
> that Oracle / Sun sense that they were published.  But, Evergreen's methods
> of access certainly could be documented better and documentation is
> generally a big challenge for open source projects as they grow.  I do not
> envy the challenge the DIG folks have though I admire what they're doing.
>
>
> Quoting Dan Scott <dan at coffeecode.net>:
>
>  On Fri, May 11, 2012 at 07:18:09PM -0700, Lori Bowen Ayre wrote:
>>
>>> Hi Devs and Community,
>>>
>>> Has there ever been serious consideration given to developing an
>>> Evergreen
>>> API?  And if not, why not?
>>>
>>> I'm just wondering if that might be something that we could make happen
>>> as
>>> a community, perhaps with funds we raise through some clever activity or
>>> by
>>> selling some groovy merchandise.  We've been talking about doing
>>> something
>>> like that on the Oversight Board although no particular project has been
>>> suggested.
>>>
>>> But, I may suggest developing an Evergreen API unless there's some reason
>>> not do.  Please advise!
>>>
>>
>> Maybe you need to define what you mean by API. If you mean "a set of
>> methods that you can call to return data or produce results", then I
>> think Evergreen has had that since day one. It would be really hard for
>> us to develop Evergreen without an API. A Google search for "Evergreen
>> API" returns this as hit #2 for me: http://evergreen-ils.org/blog/**?p=46<http://evergreen-ils.org/blog/?p=46>
>>
>> What we have could certainly use a lot more documentation in many
>> places, but we currently have native bindings for Perl, Python, Java, C,
>> and a Google Summer of Code project to pull together an official PHP
>> binding... all talking to the same API.
>>
>>
>
>
> ----------------------
> Rogan Hamby
> Manager Rock Hill Library & Reference Services
> York County Library System
>
> "Outside of a dog, a book is a man's best friend. Inside of a dog it's too
> dark
> to read." - Groucho Marx
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://libmail.georgialibraries.org/pipermail/open-ils-general/attachments/20120514/b40bdeae/attachment-0001.htm>