[ZOOM] Re: Ouch
mike at tecc.co.uk
Thu Nov 1 16:49:23 CET 2001
> Date: Thu, 1 Nov 2001 15:32:58 +0000
> From: Ashley Sanders <zzaascs at irwell.mimas.ac.uk>
> The one major difference we between ZOOM and COPAC is the connection
> object. And I'm throwing this in now as we seem to be in the mood
> for changing everything.
Er, not really. I've been reluctantly giving in to what seem to be
inevitable changes as we start writing actual client code, and the
deficiencies of the early attempts at a binding start becoming
> The ZOOM connection object is a single connection to one target. In
> COPAC the connection object can talk to more than one target. So
> when a resultSet object is created the connection object sends the
> search to as many targets as specfied by the query. Do we want to go
> down this route Mike?
As always, I welcome others' thoughts rather than wanting to present a
diktat, but I feel that this is out of scope. I would rather
concentrate on building a robust, easily comprehensible interface that
does the simple things well, and doesn't require a lot of study before
you can start doing Real Stuff with it.
4WIW, what you describe for the COPAC system's connection object
(which seems rather ill-named) is rather similar to the notion of a
ZOOM::manager, which is not described in v1.0 or 1.1 of the API in the
interests once more of simplicity, but which is implemented in the
Perl binding and documented at
> Is it also worth defining a protocol class for a resultSet
> heirarchy -- ie as base class from which all resultSet classes
> are derived?
I don't think we need to say anything about this. Application that
want to derive subclasses of resultSet can go ahead and do so without
needing any special dispensation from us. Right?
/o ) \/ Mike Taylor <mike at miketaylor.org.uk> www.miketaylor.org.uk
)_v__/\ "Why should I be tarred with the epithet ``loony'' merely
because I have a pet halibut?" -- Monty Python.
More information about the ZOOM