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

Adam Dickmeiss adam at indexdata.dk
Wed Nov 7 14:50:35 CET 2001


On Wed, Nov 07, 2001 at 12:19:36PM +0000, Mike Taylor wrote:
> > 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
> 	}
> }

For the ZOOM C implementation NamePlusRecord is the internal
representation of a single record within a result set. The API
allows you to get data, database and syntax for each record.

-- Adam
 



More information about the ZOOM mailing list