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

Robert Sanderson azaroth at liverpool.ac.uk
Wed Nov 7 13:57:00 CET 2001

> > Heh :)  I think that my misunderstanding is a -good- thing as it shows 
> > that people who just sit down and read the API might get confused.
> > So change the word 'current' to the word 'original' in the API docs and 
> > misunderstanding goes away.
> "original" is just as bad, implying as it does that you get back the
> value as it used to be when the program started!  "previous" might do
> it.

Previous would imply that if the setting doesn't get changed, then it 
should return the value prior to the current value, which is the old 
value, not the new value. Hence New -2, not New -1.

Screw it, just spell it out as to what exactly it should return in all 
situations =)  Then there's certainly no problems.

> > > interests of simplicity (and since we're all char*y), I suggest a
> > > comma-separated list.
> > Can we guarantee that no database names will include a comma?
> Nope.  But then I suppose in the end we can't guarantee that no
> database names will include a NUL either, so we just have to live with
> this sort of stupidity.

See also the slippery slope of not letting people at bits of Z39.50.
Yes I'm being pedantic, but that's what is necessary in order to be 
consistent.  This would be a precedent for -not- allowing access to 
-everything- the Z spec can do.

> > (IE What is the formal statement about characters in a database
> > name?)
> None, except that it's interpreted case-insensitively.

Ha! I was right =)

> > Something to consider, IMO, is that a lot of servers will return
> > malformed or simply incorrect diagnostics. The client will have a
> That way madness lies :-)  You're right that some servers are so badly
> broken that a client which _knows_ it's dealing with such a perversion
> Summary: feel free to write a broken client, but don't ask me to
> legitimise your deviant behaviour in the API :-)

I wouldn't call a client that can handle broken servers itself broken, but 
fair enough.  Don't try to scan some CrossNet servers, and don't try to 
search Oxford's GEAC server.  Also, forget trying to sort things ;)
For that matter, forget Explain ;)

> Indeed, this is foul and loathesome.  In time, however, Darwinian
> selection will take care of such servers.  We certainly shouldn't prop
> them up!

See also Microsoft in the press recently.  Unfortunately there are very
few commercial implementations that do things right.  Innopac is still
version two and it's one of the more common ones (in my experience)
Relying on Darwin won't see us right unfortunately, and any client that 
crashes and burns on malformed APDUs will get the blame rather than the 
broken server.

But yes, coding to the standard not the current implementations is the 
correct thing to do.

> > Is a diagnostics object too heavy a solution?
> I don't understand what you mean by "diagnostics object".

An object that maintains ( ;P ) information about diagnostics regarding a 
particular operation.  For example, simply extract the error etc 
properties from all of your current objects and have a pointer to a 
diagnostics object.


      ,'/:.          Rob Sanderson (azaroth at liverpool.ac.uk)
    ,'-/::::.        http://www.o-r-g.org/~azaroth/
  ,'--/::(@)::.      Special Collections and Archives, extension 3142
,'---/::::::::::.    Twin Cathedrals:  telnet: liverpool.o-r-g.org 7777
____/:::::::::::::.              WWW:  http://liverpool.o-r-g.org:8000/

More information about the ZOOM mailing list