[ZOOM] hello and first impressions of the C++ bindings

Mike Taylor mike at tecc.co.uk
Wed Nov 7 13:19:36 CET 2001


> Date: Mon, 5 Nov 2001 12:59:23 +0000 (GMT)
> From: Robert Sanderson <azaroth at liverpool.ac.uk>
>
> > That doesn't make sense to me. The fact that the database is a
> > list is a basic part of the protocol... why would that be out of
> > scope?  We also need a "database" value associated with each record
> > object.
>
> I think that the resultset should maintain the database, and the
> record maintain the resultset.

By "maintain" you mean "keep a pointer to", right?

This is of course an issue for individual implementations to decide,
but I'm guessing that most or maybe all implementations will have
their result sets keep a pointer to the connection which (notionally)
created them, and their records keep a pointer to the result set that
created them.  Neither will keep a pointer to a "database" _per se_
since they are not first-class objects in ZOOM (nor in Z39.50 for that
matter -- database names are merely parameters to the search request.)

In Z39.50, _records_ have associated with them the name of the
database from which they came.  See the ASN.1 definition of the
NamePlusRecord PDU:

NamePlusRecord ::= SEQUENCE {
	name	[0] IMPLICIT DatabaseName OPTIONAL,
	record	[1] CHOICE {
		retrievalRecord		[1] EXTERNAL,
		surrogateDiagnostic	[2] DiagRec,
			 -- Must select one of the above two,
			 -- retrievalRecord or surrogateDiagnostic,
			 -- unless 'level 2 segmentation' is in
			 -- effect.
		startingFragment	[3] FragmentSyntax,
		intermediateFragment	[4] FragmentSyntax,
		finalFragment		[5] FragmentSyntax
	}
}

So we should add a new method (to the abstract API as well as the C++
-- binding):

	const char *ZOOM::record::database();

(which returns null when the OPTIONAL DatabaseName is absent.)

> So record->resultset->database.

Nope -- a single result set may contain records from a variety of
database.

> This seems simpler to me than having it copied to the record object
> as well.

Yes, much simpler!  "Everything should be made a simple as possible,
and no simpler" -- attributed to Albert Einstein :-)

> [...] what use is just the name of the database and not all the
> other information on the resultset and connection objects?

That's not really for us to decide.  If we go saying, "we're not going
to let the users get at this bit of information that Z39.50 provides,
because we don't think it's very interesting", then that's a slippery
slope.

> There's vast cans of worms to be opened if we allow multi database
> searches from a single request, which I personally feel isn't
> something that ZOOM should be handling.

Really?  Seems like a nice, small can to me!

> If we can search multiple databases on a single target, then we
> should allow searching multiple databases across multiple targets
> IMO.

We do!  Even using only what's in v1.0 of the Astract API (and 1.0f of
the C++ API) you can do this just by making multiple connection
objects -- one for each target.  In the follow-up document on
asyncronous operation, we'll show how you can call the search() method
on a _manager_ to search asynchnronously over all the connections
which it contains.

> I've not looked at the spec for this (never needed to) but I assume
> that only one resultset is created for the combined search? Or does
> it create one resultset for each database?

The former.

> There seems to be nasty issues with both ways.  (eg distinguishing
> origin of records, vs somehow returning multiple result sets)

See the NamePlusRecord PDU above.

> Encapsulation of search and sort is, now, part of the protocol but I
> don't think we need to have that either ;)

I _think_ we can leave that to implementations to do behind the scenes
if we want to.  Not sure, haven't thought about it hard enough.

 _/|_	 _______________________________________________________________
/o ) \/  Mike Taylor   <mike at miketaylor.org.uk>   www.miketaylor.org.uk
)_v__/\  "The cladistic defintion of Aves is: an unimportant offshoot
	 of the much cooler dinosaur family which somehow managed to
	 survive the K/T boundry intact" -- Eric Lurio.




More information about the ZOOM mailing list