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

Mike Taylor mike at tecc.co.uk
Tue Nov 6 14:05:49 CET 2001

> Date: Sun, 4 Nov 2001 02:03:56 +0100
> From: "Jacob Chr. Poulsen" <ja7 at dbc.dk>
> First i wan't to say that i like the ide of the ZOOM abstraction. 

Hello, welcome aboard!

> - why is the set option call retyrning the old value?
>   i wood argue that close to all clients setting a option is
>   not interested in the old value. and if it ware the call of
>   the get function is not be a  large overhead.

There's a long discussion about this later in the email archive in
which Rob displays total misunderstanding about this (sorry Rob! :-)
Adam's interpretation of my intentions here is the correct one: like
signal() the Set Option method was intended to return the old value.
I certainly don't want to see code like:

	if (!!strcmp(conn->option("databaseName", "foo"), "foo"))
		fatal("couldn't set option")

And I think that the passage that someone quoted from the abstract API
makes that clear.

However, given that the potential for such misunderstanding exists,
maybe it would be better to change the C++ binding so that the
two-argument version of the option() method returns void?  Maybe (as a
wise man once wrote) "each [method] should do one thing well".

> - The record object is trying to do stuff that others do betters.
>   eg. if I was dooing a client which was using xml. i wood proberly
>   have a som libs ad hand to handle the xml, and the samme gos for any 
>   other recordsyntax.

Yes indeed.  It is certainly not our intention to have ZOOM's record
handling intrude on existing, dedicated software which does the same
job much better.  When appropriate (*MARC, XML), we want to get the
record out in a big lump and hand it over ASAP.

>   many excluding grs-1 which seams to be invented for Z3950.

Yes, I think we all agree that ZOOM must address GRS-1 more or less

> - personaly i think the ZOOM api shut returns records as octetsreams, and 
>   let the client application decode the record. optionaly supply a support
>   lib for GRS-1. 

That's what the rawdata() method will get you do, one way or another.
We're still discussing exactly how this will happen -- or at least, I
asked what I thought was an important question on this subject before
my (long) weekend, but no-one seems to have responded yet, so here it
is again:

	In summary, the problem here is that "raw data" means
	something different for different record syntaxes.  For MARC
	records, it really does mean an opaque block of bytes, but for
	GRS-1 record nobody wants that (and not all low-level toolkits
	even support it.)  So we need a way to provide access to
	different stuff depending on what kind of record we're dealing

	The MARCRecord class (and its subclasses) will provide simple
	access to the really-raw data: e.g.

		class MARCRecord {
		    // ...
		    const char *bytes(size_t *sizep);

	Whereas the GRS1Record class will provide a very different set
	of methods (yet to be designed) allowing you to do the obvious
	sorts of things -- walk the tree, etc.

	[Side issue: I think we were wrong to take the MARCRecord type
	out of the API: we should include it so that we can
	standardise the bytes() method, or whatever we call it.]

	Now we decided that rather than add the recordtype-specific
	methods to the record class subtypes themselves, we'd add them
	to the parallel hierarchy of data class subtypes.  I would
	welcome input from anyone who remembers why we decided to do
	it that way!

In case anyone didn't "get" that, the message is that I am starting to
think that the rawdata objects are an extra layer of added complexity
for no or marginal gain.

> - Howto is one access multible database on the same target. i am missing 
>   a list of databases as part of the search class.

The database to search is specified by the "databaseName" option --
see section 3.2.3 of the abstract API at

The next version should specify how this option's value can specify a
list rather than a single database name.  In the interests of
simplicity (and since we're all char*y), I suggest a comma-separated

> My initial comments to the zoom-1.0f.hh this is not in any order just 
> writen as i notes stuff warking tru the .hh file.
> - There is to many char* why not use std::string. 
>   if wirried about to much copying use references

It would gain us nothing.  (We ought to have a FAQ about this!)	 The
char*s are opaque tokens and are never manipulated, so we don't need
any of the functionality that std::string would offer.

> - To me it don't semams as the connection obejct shut be copyed. 

I agree (does anyone not?)

>   if it is, the question arises a what is the semantics of copying a
>   connection.  if the connection shut not be copyed the make a
>   private copy constructor and assignment operator. 

OK, does the existence of a private constructor actually change the
public interface of a C++ class?  What a stupid world!  So our
public, abstract version of the binding's header-file needs to include
private methods, so that their existence can imply the absence of the
ability to copy connections?  Arrrgh!

> - enum ZOOM::record::recordSyntax, a enu of record syntaxes will
>   allways be wrong.  in my current work we uses
>   1.2.840.10003.5.1000.105.221 to send special present formats. and
>   as it is a private OID used.

This is an excellent point - we don't want to preclude the use of
non-standard record syntaxes.  Anyone want to propose a good way to
handle this?

> - I can't figure how the errors is to be returned, in the Abstract
>   API 3.4.6, about the errcode, errmsg,addinfo, and a not saying
>   that the language binding is allowed to throw the sam info as
>   exceptions. and i the diags is comming as exceptions then there is
>   no object to ask for the error coded and eg. no need for the
>   functions in the resultset class.  I wood prefere errors as
>   exceptions, but is haveing a problem with howto represent multible
>   diagnostics from a search.

See the discussion archive at http://www.indexdata.dk/pipermail/zoom/
for some insight into this.  You're right, the diagnostic interface
remains muddy -- perhaps because the abstract API allows too much
leeway.  Who will propose a GUT to fix this?

Thanks for these contributions.

 _/|_	 _______________________________________________________________
/o ) \/  Mike Taylor   <mike at miketaylor.org.uk>   www.miketaylor.org.uk
)_v__/\  "Schuh's book is very good, but [...] some of us would apply
	 his definition of `definition' to `diagnosis', and would
	 `define' on descent" -- Chris Brochu.

More information about the ZOOM mailing list