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

Mike Taylor mike at tecc.co.uk
Wed Nov 7 13:37:34 CET 2001

> Date: Tue, 6 Nov 2001 13:56:28 +0000 (GMT)
> From: Robert Sanderson <azaroth at liverpool.ac.uk>
> > > - why is the set option call retyrning the old value?
> > There's a long discussion about this later in the email archive in
> > which Rob displays total misunderstanding about this (sorry Rob! :-)
> 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

> As you pointed out at the ZIG, if we use the AAPI then we don't need
> to write our own docs... but the flip side is that the ZOOM docs
> need to be very carefully written.

Absolutely agree!  That's why I will be soliciting very careful
reading and picky comments on v1.1 when I get that done.

> > 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 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.

> (IE What is the formal statement about characters in a database
> name?)

None, except that it's interpreted case-insensitively.

> Or is this not important enough to bother with?

That's my feeling, but I welcome others' thoughts.

> Something to consider, IMO, is that a lot of servers will return
> malformed or simply incorrect diagnostics. The client will have a
> better idea of what is actually going on at certain times than the
> official diagnostics.

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
can make a good guess at the real cause for errors.  But there's no
way in general for the client library to know which servers fall into
that category, so if it starts trying to second-guess the server, then
the odds are very much that we're going to make things worse.

Summary: feel free to write a broken client, but don't ask me to
legitimise your deviant behaviour in the API :-)

> When trying to do a simple SCAN on one server that advertised as
> supporting it, it returned code 6 - Too many boolean operators.
> Err... No, it's just a broken implementation.
> Also several implementations do not conform to the standard as applies to 
> v3's AddInfo on diagnostics which is NOT optional.

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

> Is a diagnostics object too heavy a solution?

I don't understand what you mean by "diagnostics object".

 _/|_	 _______________________________________________________________
/o ) \/  Mike Taylor   <mike at miketaylor.org.uk>   www.miketaylor.org.uk
)_v__/\  Overweaning, participle vb. -- force-feeding a baby with
	 pieces of steak.

More information about the ZOOM mailing list