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

[Nathan Eady]

Mike Rylander wrote:

>> 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 ...

Makes sense.

> 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.)

I have now.

One small thing I have found so far that is unclear to me is the
explanation about registering ejabberd users.  The referenced script
for doing it asks for four args:  server, port, username, password.
The explanation suggests four users that should be registered, and
I suppose that for a single-machine install server should presumably
be localhost, but I don't know enough about jabber (or perhaps about
how OpenSRF uses it) to know what port to specify.

>> 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.  

I didn't mean for testing the config file itself, but for testing
the code that reads it.

 > 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.

Okay.  I'll probably at least create a minimal test for any code
I write, if nothing else because I don't want to submit totally
untested code, so there'll be at least a start to work from.
Then we can go from there.

> 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.  

Interesting thought.  I'll keep that in mind.

> 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. ...

Seems reasonable.

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

I don't dislike DOM.  Looking at LibXML again now, I suspect that for
past projects I avoided it because it isn't pure Perl.  (I was trying
to keep non-pure-Perl dependencies down for what I was doing at the
time.)  The considerations here are obviously a bit different.