[ZOOM] pointers (fwd)

Ashley Sanders zzaascs at irwell.mimas.ac.uk
Thu Nov 1 17:04:55 CET 2001


Rob,

> > I suggest that we take the bold step of _throwing away_ the search()
> > method from the ZOOM::connection class, and _replace_ it with a
> > resultSet constructor whose arguments are a connection and a query.
> 
> I have two main concerns with this approach:
> 
> 1)
> >From the API:
> "A result set represents a set of records, held on a server, which have
> been identified by searching."
> 
> As we all know, there's several implementations out there that don't
> support named resultsets.  This means that the default resultset will be
> reused for each search.  I think it's counter productive to assume that a
> 'new' resultset will be created for a search.  In fact, a well behaved
> implementation would reuse a named resultset object for a search that
> returns its results with the same name rather than creating a new object
> with the same name, which is what is implied from a search via a
> constructor.

The idea of ZOOM was to hide the z39.50 funnies from the user
(and named/not named result sets is definately something that
wants to be hidden from the user.) So a search should _always_
create a new resultSet -- whether the target supports named
result sets or not. For my own stuff, the resultSet "remembers"
the query, and if needs be will silently re-run the query
in the background. You can see (or rather you can't) this
happening at:

    http://copac.ac.uk/msgw/wzgw

which is our new, experimental (bug reports to me please),
interface using the COPAC origin I've been batting on about. Of
the three targets it's set up to search NLS doesn't support named
result sets.

Ashley.

-- 
Ashley Sanders                                a.sanders at mcc.ac.uk
COPAC: A public bibliographic database from MIMAS, funded by JISC
             http://copac.ac.uk/ - copac at mimas.ac.uk



More information about the ZOOM mailing list