No subject
Fri Apr 16 10:15:54 EDT 2010
functionally complete as the C code, possibly more so in some respects.
It's just not battle-hardened, so it probably has some bugs and/or areas
that need better fault tolerance. I think it would make a suitable
reference implementation, though. It's the most recent implementation (so
it's very much to-the-point), the code is relatively clean, and Python is
easy to read. Also, the IDL code in the Python Evergreen modules is up to
date...
Good luck. I hope this helps.
-b
--
Bill Erickson
| VP, Software Development & Integration
| Equinox Software, Inc. / Your Library's Guide to Open Source
| phone: 877-OPEN-ILS (673-6457)
| email: erickson at esilibrary.com
| web: http://esilibrary.com
--20cf3054a5b7ae453d04990a8710
Content-Type: text/html; charset=UTF-8
Content-Transfer-Encoding: quoted-printable
Hi John,<br><br><div class=3D"gmail_quote">On Tue, Jan 4, 2011 at 10:10 AM,=
John Craig <span dir=3D"ltr"><<a href=3D"mailto:jc-mailinglist at alphagco=
nsulting.com">jc-mailinglist at alphagconsulting.com</a>></span> wrote:<br>=
<blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1p=
x #ccc solid;padding-left:1ex;">
<div bgcolor=3D"#ffffff" text=3D"#000099">
<font face=3D"Helvetica, Arial, sans-serif">Hi Folks,<br>
<br>
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=C2=A0 questions some of you folks who are more in the kno=
w
might be able to answer:<br>
<br>
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)?</font></div></blockquote><blockquote c=
lass=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;=
padding-left:1ex;"><div bgcolor=3D"#ffffff" text=3D"#000099"><font face=3D"=
Helvetica, Arial, sans-serif">
<br>
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?<br></font></div></blockquote><div><br></div><div>Th=
e Java client was designed to be a full-featured OpenSRF client and, at the=
time, from what I recall=C2=A0(It's been a few years since I last used=
it), it behaved much like any OpenSRF client. =C2=A0I glanced at the code =
today to refresh my memory and was pleasantly surprised to see that, at fir=
st glance, it appears to be generally consistent and up to date with the re=
st of OpenSRF (i.e. > version 0.9). =C2=A0I'm positive there are bug=
s and almost certainly some missing pieces, but repairing them should not r=
equire large architectural changes to the code.</div>
<div><br></div><div>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. =C2=A0One issue that comes to mind is the loss of &q=
uot;array_position" for IDL fields. =C2=A0open_ils.idl.* will need som=
e attention to resolve that.</div>
<meta charset=3D"utf-8"><div><br></div><blockquote class=3D"gmail_quote" st=
yle=3D"margin:0 0 0 .8ex;border-left:1px #ccc solid;padding-left:1ex;"><div=
bgcolor=3D"#ffffff" text=3D"#000099"><font face=3D"Helvetica, Arial, sans-=
serif">
<br>
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?<br></font></div></blockquote><div><br></div><div>From the perspectiv=
e of an OpenSRF client, the Python code is as functionally complete as the =
C code, possibly more so in some respects. =C2=A0It's just not battle-h=
ardened, so it probably has some bugs and/or areas that need better fault t=
olerance. =C2=A0I think it would make a suitable reference implementation, =
though. =C2=A0It's the most recent implementation (so it's very muc=
h to-the-point), the code is relatively clean, and Python is easy to read. =
=C2=A0Also, the IDL code in the Python Evergreen modules is up to date... =
=C2=A0 =C2=A0=C2=A0</div>
<div><br></div><div>Good luck. =C2=A0I hope this helps.</div><div><br></div=
><blockquote class=3D"gmail_quote" style=3D"margin:0 0 0 .8ex;border-left:1=
px #ccc solid;padding-left:1ex;"><div bgcolor=3D"#ffffff" text=3D"#000099">
</div>
</blockquote></div>-b<br><br>-- <br>Bill Erickson<br>| VP, Software Develop=
ment & Integration<br>| Equinox Software, Inc. / Your Library's Gui=
de to Open Source<br>| phone: 877-OPEN-ILS (673-6457)<br>| email: <a href=
=3D"mailto:erickson at esilibrary.com">erickson at esilibrary.com</a><br>
| web: <a href=3D"http://esilibrary.com">http://esilibrary.com</a><br>
--20cf3054a5b7ae453d04990a8710--
More information about the Open-ils-dev
mailing list