Re: ZNG: "Z39.50 Next Generation"

On Fri, Jul 13, 2001 at 02:12:41PM +0200, Pieter Van Lierop wrote:
> I am sceptical about the idea of trying to make a "mainstream protocol", if
> only because "mainstream" means "simplified" which means "poor". I think we
> need an upgrade of Z39.50 for libraries, documentation, full-text retrieval,
> that kind of things. Let us stick to our business, and not try to conquer
> the whole world.
> Z39.50 was a tremendous success, and it will be hard to repeat that.

We develop a document management/full-text retrieval product (as
distinct from a library system) and while it has given us tick boxes on
tender responses, customers have rarely used it. Why? Because the
customers want to develop swish user interfaces. What products do they
use for this? Things like IIS and WebSphere. For scalability, these
products recommend *against* session based APIs. Every request must be
a stateless transaction. If this is achieved, it is trivial to distribute
your application across N-boxes, there is lots of switching hardware
available, and so on, to build large scale solutions. Its where most
of the industry (rightly or wrongly) is going.

So Z39.50 might be a success in libraries, but I have seen no evidence
(in my experience) that it has had any "success" in other fields.

> I am a partisan of the Scan functionality, and I will defend it!!

I think scan needs to stay too.

By the way, to me (remember I am not a library person), the main
contribution of Z39.50 is both its strength and weakness. The main
advantage is its data model with the abstraction of search points
from the physical representation of data. Scanning of index terms
is a secondary differentiator.

Result sets etc is all good stuff, but is not how application servers
seem to be moving (have moved!). Everything must be an individual
stateless transaction. This is why in the past I have been so
interested in XER and encapsulation. Its what our customers ask
for. (Mind you, they also ask for performance which the stateless
approach will do a *worse* job of - but scalability seems to be
considered more important than response time in a single request
because if the machine is overloaded, the response time goes
down anyway.)

Alan

Received on Sunday, 15 July 2001 19:42:15 UTC