Bindings

Binding Specifications

An API that you can't implement is useless, so from the beginning of the ZOOM initiative, we have worked with concrete bindings of the abstract API to specific languages. This has enabled us to test the utility of the interface by creating real applications

In general, a language-binding of an API is a non-trivial specification in itself, and is well worth a document of its own. Our goal is to find people to take responsibility for each individual binding. If you feel able to contribute to one or more bindings - either those already being worked on, or brand new bindings - please contact us at <bindings@zoom.z3950.org>

Implementations

Of course, even bindings are useless if they're not implemented. In an ideal world, every binding would have multiple implementations, and they would compete for market share based on factors such as price, reliability, efficiency and availability of support, just as, for example, the various web servers - all of which implement standard HTTP - compete for market share,

We would very much like to see more implementations of the ZOOM client model. This will test the robustness of the model and the clarity of the specification as well as providing application programmers with a broader pallette of tools from which to choose. In particular, many of the existing reference implementations are written on top of the YAZ Toolkit from Index Data. We specially welcome implementations written on top of other low-level toolkits such as Crossnet's ZedKit and OCLC's tools.

Current Bindings/Implementations

Here, we offer overviews of the existing ZOOM binding specifications, together with their implementations. Different bindings are at very different levels of maturity, but these nine each have at least one freely available working implementation:

• The C Binding
• The C++ Binding
• The Perl Binding
• The Python Binding
• The Java Binding
• The Visual Basic Binding
• The Scheme Binding
• The Tcl Binding
• The Ruby Binding
• The .NET Binding
• The Squeak Binding
• The NodeJS Binding [NEW]

The following languages and environments have been the subject of at least some speculation concerning ZOOM bindings. Some of them are much further advanced than others - for example, the Ada binding is fully specified, and work has begun on an implementations.

• The PHP Binding
• The Ada Binding
• The Shell-Commands Binding
• The ``Web Services'' Binding
• The Corba IDL Binding

We hope that additional bindings will be specified for appropriate languages. There are not many obvious candidates left, but we would particularly welcome a bindings and implementation in your favourite language!

To give a flavour of the existing bindings, there is a ``Hello World'' Zoo containing a simple ZOOM program expressed in a variety of languages.

Note: Version Numbers

In an attempt to keep some sense of unity to this sprawling development effort, I'm trying to impose quite a strict version numbering scheme. Here it is.

• The abstract API version numbers can do what they want so long as they always increase and never go backwards. I can go from 1.x to 2.0 whenever I like :-)

• Every language binding that is specified against a version foo of the abstract API is given a version number consisting of foo followed by a single letter. The letters of the various versions must start at a and progress through the alphabet: the increasing letter suffixes indicate increasing maturity of the binding for that version of the API. If you need more than 26 releases of a binding against one version of the API, you're doing it wrong :-)

  For example, the first few version of the C++ binding that captures version 1.0 of the abstract API are versions 1.0a, 1.0b, 1.0c, etc.

• Every version of a given implementation of a version foobar of a binding is given a version number consisting of foobar followed by a number. The numbers of the various versions must start at 1 and increase: the increasing letter suffixes indicate increasing maturity of the implementation of that binding.

  For example, the first few version of any given implementation of C++ binding version 1.0e are 1.0e1, 1.0e2, 1.0e3, etc. (Yes, this reads like a series of real number. So?)

  We hope, of course, that there will be multiple implementations of any given binding. It's perfectly OK for (say) the Manchester University implementation of the C++ binding to be at version 1.0e5 while (say) the Index Data implementation is only at 1.0e3.

This means that every version of every implementation of every binding has a version number packed with juicy information. If it's called (say) 2.7g3, then we know it's:

• An implementation of v2.7 of the abstract API.
• An implementation of v2.7g of the C++ binding.
• Release 3 of that implementation.

I hope that's (A) clear, (B) helpful, and (C) not too oppressive.

Note (16th May 2003). Pretty much without exception, every binding specification and implementation seems to have ignored this convention. Oh well - worse things happen at sea.