Re: Converting 'an' API to run against QUIPU

[[e-mail]]

Christian,

I am afraid that I do not agree with your thoughts about APIs.

First, however, I most certainly agree with:

> The scheme that you describe is not a response to the "QUIPU DUAs to
> talk to QUIPU DSAs", but rather to the "random API conversion"
> question. You dont need an API -- and certainly not the lousy X.Opens
> %^$#@ stuff -- for DUA to DSA connections. In fact, we do it every
> day when connecting a Pizarro DUA to a QUIPU DSA and vice-versa:
>
>	Pizarro Interface,
>	Pizarro DUA,                               QUIPU DSA
>	INRIA Session, Transport                   ISODE Session, Transport
>		----------------                   --------------
>		------- Choice of TCP-IP or X.25 ------------

Indeed the ability for products from different vendors, using different
implementations, to work together is the point of standards.

> The role of "standard API" is to let you develop an application
> independantly of the implementation of the local stack. Such a design
> is in my opinion very questionable: the interface is in most case
> directly generated by your stub compiler, e.g. MAVROS for INRIA,
> ROSY+PEPY for ISODE; converting to a "generic" interface like X.OPEN
> is generally time consuming, boring, and ineffective.

I'd agree with time consuming and boring (to write, anyway). It is,
however, absolutely necessary.

One of the advantages of standards is the ability to mix and match
vendors. There is no necessity to purchase the DUAs and DSAs from
the same vendor. Indeed, I'd expect that this will become extremely
uncommon. Specialist DUA vendors will spring up marketing DUAs
tailored for particular niche markets. Other vendors will provide
DUAs as an auxiliary to their main product; one obvious example is
an X.400 vendor that builds a DUA into their X.400 user agent.

Now, from the point of view of the user of X.500, you don't need a
common API to run DUAs from different vendors on one box. Each DUA
can come packaged with its own implementation of the transport,
session, presentation, and application layers (I'll refer to this
software, including ASN.1 compilers etc, as the 'protocol stack').
The cost to the user of this approach, of course, is that of the
disk space required to store the various libraries and the size of
the running processes. Also, of course, don't forget the cost of
installation and the maintenance of the configuration information.

Ideally a user wants only one protocol stack on the machine and only
one set of configuration information to learn!

Of course, as a software developer I don't really care about the poor
user (:-), I'm concerned about my own difficulties and costs. Actually,
this is not quite true. If a user really needs my DUA then they will
put up with supporting a new protocol stack. If, however, they don't
really need it then they will look at whether they can justify spending
the money on the protocol stack, and the machine and human resourses
necessary to run it. In short, the choice of protocol stack on which
I develop my DUA may limit my potential sales.

The choice of protocol stack will heavily influence the code I write
in my DUA. Much of the code I write will be examining or setting the
contents of fields in the interface. In addition, the models used
by the interface to initialise and control the interface; pass X.500
protocol information across the interface; and manage memory will
affect the structure and design of my DUA. The point is that a DUA
is written around a particular interface. To subsequently port it
to another interface is a non trivial task and may, in fact, be
equivalent to completely rewriting the code. This raises subsequent
problems (and costs) with future maintenance of my code.

I've already mentioned one reason why I might want to port a DUA
(potential sales). There is another reason as well.

Writing a DUA to a particular protocol stack ties you to that
particular stack and that particular vendor. This can be a very bad
thing.

Simply, as a small software developer you have little (if any)
influence on the vendor of the protocol stack. This is particularly
true if you are beyond the edge of civilisation (e.g. in Australia :-).
The success of your product is tied up with the success of another
piece of software over which you have no control.

What happens if the protocol stack vendor goes out of business? Or,
more likely, simply ceases development work or bug fixing on the stack?
How much will it cost when the vendor unilaterally decides to change
the interface without warning, requiring extensive rewriting of your
DUA? What do you do if, having locked yourself into one protocol
stack, the vendor decides to drastically increase the price of their
product?

The use of a standard API mininises these risks. It also has another
benefit. If a different vendor brings out an improved implementation
of the API that is faster, smaller or cheaper it is easy to port your
code.

None of these benefits are technical.  These are commercial benefits I
gain as a very small software developer with no effective influence
over the vendors of protocol stacks.

andrew waugh

p.s. None of this is a criticism of the Quipu interface which we
currently use. I have had no problems with the Quipu developers.
My only problem with Quipu is that, as it is not a 'commercial'
product many companies are very reluctant to run Quipu.
Strange but true. It does, however, limit potential sales!