[OPEN-ILS-DEV] Getting there -- bootstrapping OpenSRF Client problem

[Mike Rylander]

On 12/14/06, Nathan Eady <eady at galion.lib.oh.us> wrote:
> Mike Rylander wrote:
>
> > It just happened that way.
>
> I see.
>
> >> If the latter, would it be good at some point to get the Perl
> >> services to read from the XML config file?
> >
> > That's on the roadmap, for sure.
> >
> >> That sounds like something that could be done by someone who
> >> speaks Perl but is not very familiar with the codebase yet...
> >
> > And that sounds as much like an offer as we'll ever get! ;)
>
> It might be.  I don't know how quickly I can get something done,
> but I'll put it on my radar.  Because, as a long-term goal I'd
> like to become familiar with this codebase, and to do that I've
> got to start someplace.

Absolutely ... that's about where we started, so it's as good a place as any.

>
> > You can take a look at http://ln-s.net/GZs (Web CVS repo) to see what
> > we're doing now.
>
> Oh, good, it's gathered in one file, the reading, the writing,
> and the API all in one place.  That's helpful.
>

Right, though all we really need is an OO-ish read-only interface to
the XML config file (or, more specifically, an analogous chunk
thereof) that's shaped the same as the automagic interface built by
that module.  Even that module was probably overkill for what we use
of it, but it was there and worked ...

> I will have a more detailed look at it, once I get stuff installed
> on my workstation.  (I did an anon CVS checkout, but I don't seem
> to see the file opensrf_core.xml, so I imagine it is probably
> created at install time.  I will of course need to have a look at
> its structure if I'm going to implement an interface to it.  I
> wanted to have an installation to play around with anyway, so I'm
> installing the dependency bundles now...)

If you're attempting to install the CPAN bundles you'll likely be
disappointed -- they are way out of date (and may never be updated).
The top level dependencies are all listed on the wiki, though, and you
can find them (some for specific Linux distros) here:
http://open-ils.org/dokuwiki/doku.php?id=server_installation .

(I'm sure you've seen that, though.)

>
>  > We'll need to keep things API compatible since we use the
>  > O::U::Config interface extensively in the perl innards, but
>  > it's certainly doable, I think.
>
> I don't suppose there's already a test suite for the Config API?
> If not, is there a preferred test framework (e.g., Test::More or
> whatever)?
>

There's not, and there's so little to it that a DTD (once it's
XML-based) is really as far as I've thought of going down that general
road, honestly.  If you'd like to start with a test-first approach
then any scaffolding you're familiar with is fine, I think.  I've used
Test::Harness in the past, but Test::More seems more popular these
days.

There's no unit testing to speak of currently, so that in general
would be both a big help and a great way to learn the codebase.  If
you /do/ decided to go that route, I'd definitely suggest starting in
the OpenSRF branch of the codebase, as it changes much less often. ...
Well, except for the big ol' wire protocol change we have planned for
soon-ish, but that should only effect the JSON parser/generator.

> > We already use XML::LibXML in the perl stuff, so that's the
> > natural/prefered choice for the XML parser, but we do have a
> > dependancy on XML::Simple for some outlying pieces, so if that
> > simplifies things then it would be acceptable as well.
>
> I will look at these, especially the former.  Most of my Perl/XML
> experience up to now has been with XML::Twig, but it never hurts to
> add a tool to my toolbox.
>

XML::LibXML is a joy to work with if you like DOM.  It made porting
some stuff to both Javascript and C much easier.

-- 
Mike Rylander
mrylander at gmail.com
GPLS -- PINES Development
Database Developer
http://open-ils.org