[moby] Re: [MOBY-dev] CommonSubs.pm: complexResponse

Wed Nov 23 21:05:47 UTC 2005

On Wed, 2005-11-23 at 10:01 -0500, Frank Gibbons wrote:

> So Mark, if I understand correctly, it should first check to see if the 
> user has defined those environment variables. That should indicate that the 
> user does have a local registry.

Not necessarily local - the environment variables are simply a way of
specifying which MOBY Central you wish to talk to by default (i.e. when
you don't initialize the MOBY::Client::Central object with a
"Registries" parameter).  

The following statements describe what happens:

1)  The MOBY::Client::Central module is hard-coded to default to
mobycentral.icapture.ubc.ca  as it's default registry

2)  When it is initializing, it first checks for the MOBY_SERVER and
MOBY_URI environment variables and uses those instead of the defaults if
they exist, otherwise it will default.

3)  Initializing MOBY::Client::Central using the "Registries" argument
will over-ride both of the previous behaviours
	-> use of this argument also allows you to interact with more than one
registry at a time (for **read-only** interactions) ...(note that this
latter behaviour has never been adequately tested, since it has never
been used AFAIK)

>  It should a local registry if available, 
> but fall back to using MOBY Central  if it's not available. Right?

yup.  That behaviour has always been true, actually; however the test
harness was hard coded to use the 'Registries' argument when it started-
up, so it was over-riding the useful behaviour that
MOBY::Client::Central already had :-)

The same behaviour is now true for MOBY::Client::OntologyServer - it
will first check the environment variable, and if it isn't set, then it
will default to call home to mobycentral.icapture.ubc.ca

Cheers!

M

> That'd be awsome!
> 
> -Frank
> 
> 
> >M
> >
> >
> >
> >Frank Gibbons wrote:
> >
> >>Congratulations, Pieter,
> >>
> >>At 08:32 AM 11/21/2005, you wrote:
> >>
> >>>One more thing. After my changes I tried make test and noticed that
> >>>the Config.t is skipped, because it's only required for a local
> >>>BioMOBY Central..., but I do have one and I have set my
> >>>MOBY_CENTRAL_CONFIG env var. I looked at the code, but are not very
> >>>familiar with the test scripts...
> >>
> >>
> >>I think you just got yourself nominated to be caretaker of the test 
> >>t/Config.t. I don't have a local registry, so there was no way for me to 
> >>test its operation. Most users (I think) are in the same position, so 
> >>this test is skipped by default.
> >>
> >>For details on how to use the testing framework, you could look at
> >>the Perl modules Test::Simple and Test:More. The basic idea is that you 
> >>execute some MOBY code for which you believe you know the output. You 
> >>compare actual output to expected output using the is() function. It 
> >>generates errors if the two don't match. You can also check for correct 
> >>failure using isnt(), which generates a similar error. Examples might be:
> >>
> >>is(2+2, 4, "Can't do addition");' # Generates error with this string 
> >>showing up on output device
> >>is(scalar @A, $#A + 1, "Scalar gives incorrect results");
> >>
> >>Generally, tests should be symbolic, rather than specific. This leads to 
> >>tests that are more easy to maintain over time: if an array is built 
> >>before it is tested, and if it's tested symbolically, it should be 
> >>possible to alter the array contents at a later point, without breaking 
> >>that test. Take a look in the Client-Central.t for examples of this: a 
> >>registration structure is created, services are registered, then the 
> >>registration object is itself queried, and the results compared 
> >>symbolically with the original data. This verifies that the information 
> >>flows through the system correctly. If someone later decides to change a 
> >>small detail (e.g., a parameter name), the tests should continue to pass 
> >>without modification.
> >>
> >>But the tests themselves don't really have to complicated to be useful: 
> >>check that each module exports the functions it claims to implement, 
> >>check that set/get methods work correctly, check return types in all 
> >>contexts (does it return array in list context, scalar in scalar 
> >>context). All that stuff is important in maintaining a coherent interface 
> >>over time. It also helps to find inconsistencies.
> >>
> >>I think it would be really great if you could build some useful, robust, 
> >>portable tests for the local-registry configuration. This kind of test 
> >>can be a big help to users trying to install their local registry, so its 
> >>utility goes beyond merely regression testing the code, it's also useful 
> >>to debugging local installations with perfectly functioning code.
> >>
> >>-Frank
> >>
> >>PhD, Computational Biologist,
> >>Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
> >>Tel: 617-432-3555       Fax: 617-432-3557
> >>http://llama.med.harvard.edu/~fgibbons
> >>_______________________________________________
> >>MOBY-dev mailing list
> >>MOBY-dev at biomoby.org
> >>http://www.biomoby.org/mailman/listinfo/moby-dev
> >>
> >
> >_______________________________________________
> >MOBY-dev mailing list
> >MOBY-dev at biomoby.org
> >http://www.biomoby.org/mailman/listinfo/moby-dev
> 
> PhD, Computational Biologist,
> Harvard Medical School BCMP/SGM-322, 250 Longwood Ave, Boston MA 02115, USA.
> Tel: 617-432-3555       Fax: 
> 617-432-3557       http://llama.med.harvard.edu/~fgibbons 
> 
> _______________________________________________
> MOBY-dev mailing list
> MOBY-dev at biomoby.org
> http://www.biomoby.org/mailman/listinfo/moby-dev
-- 
"Ontologists do it with the edges!"

Mark Wilkinson
Asst. Professor
Dept. of Medical Genetics
University of British Columbia
PI in Bioinformatics
iCAPTURE Centre
St. Paul's Hospital
Rm. 166, 1081 Burrard St.
Vancouver, BC, V6Z 1Y6
tel: 604 682 2344 x62129
fax: 604 806 9274