[OPEN-ILS-DEV] ***SPAM*** Appropriate updates to Java OpenSRF/Open-ILS API

[Bill Erickson]

Hi John,

On Tue, Jan 4, 2011 at 10:10 AM, John Craig <
jc-mailinglist at alphagconsulting.com> wrote:

>  Hi Folks,
>
> Last month, Dan Scott and I had some discussion on the IRC channel about
> our working with the less-used Java API and the fact that it needed some
> updating. In the course of our work, we've added the ability for it to
> handle some additional message/response types. As we might as well be sure
> we've done what we can to improve the API (in addition to needs we happened
> upon in the application we were working on), I have a few  questions some of
> you folks who are more in the know might be able to answer:
>
> 1) What things come immediately to mind in terms of the API needing to
> support OpenSRF interactions/operations/functionality that are new since the
> Java API was originally created back when OpenSRF was at 0.9 (or whatever
> the exact version was)?
>

> 2) Given that the Java API was, iirc, intended to provide some quite
> specific capabilities (in support of early Acq efforts), was anything in
> particular left out?
>

The Java client was designed to be a full-featured OpenSRF client and, at
the time, from what I recall (It's been a few years since I last used it),
it behaved much like any OpenSRF client.  I glanced at the code today to
refresh my memory and was pleasantly surprised to see that, at first glance,
it appears to be generally consistent and up to date with the rest of
OpenSRF (i.e. > version 0.9).  I'm positive there are bugs and almost
certainly some missing pieces, but repairing them should not require large
architectural changes to the code.

The Java Evergreen libraries are more likely to be out of date, since there
has been more shift on the EG side than OpenSRF in the last couple of years.
 One issue that comes to mind is the loss of "array_position" for IDL
fields.  open_ils.idl.* will need some attention to resolve that.


> 3) The documentation mentions using the Python API as a reasonable model
> for a port to another language. I know there's been some recent work on the
> Python API; is it essentially functionally complete at this point?
>