| I'll observe that MRU had an "api" since before it was ported
to Digital UNIX for V1.0. The CLI consisted of all command
line stuff in a source file and a common set of routines
with the mrd_ prefix for doing load, unload, show, etc, and
an operating system interface under that.
V1.1 only cleaned up the interface some, let mrd_show() get
information on more than one element and added mrd_move().
V1.2 adds even more features. In V1.1 the VMS version of
"api" becomes a shared library that would used by all the
SMS VMS products that needed media changer control. The
conversion of what are now three object files on the three
platforms (common, os specific, message stuff), to an API
is a small matter of:
o Building an object library.
o Building a shared library, where appropriate.
o Extensive testing.
o Even more extensive documentation.
o Politics.
One would be safe to assume that the first part is easy. The
2nd part probably is. The 3rd part never is. There is more
to documentation than a help file or manual pages. Those are
a good start though and part of that was done recently. More
needs to be done.
The last part is the hard one. First, the API has to make a
profit, or there is no reason to do any of the other work.
Must we sell 100 at 10,000 each or 1,000 at 1,000? For
any given target, play the game of finding the balance of
numbers.
Second, if we intrude too much on the space of other products,
they could lose sales. A backup solution might lose sales to
competitors that use MRD for their medium changer control. Can
the extra sales of MRD make up the lost sales of that backup
product?
Having said all this, my feeling is if we don't provide customer
something they'll go to somebody who will. Such as it is, the
MRU API isn't far from being a good enough solution. But going
the *Product* route is very hard and fraught with peril. At the
same time we could find imaginative ways of making an API available
on a limited basis.
So, talk to Bryan.
|
| Thanks, Alan, for laying out the alternatives. I'm going to go back to the
customer with the existing alternatives (/dev/cam, license MCI) and see what
they think. If neither of those are sufficient, I will discuss further with
Bryan.
Norm
[Posted by WWW Notes gateway]
|
| By popular demand, we'll be making the MRU API available with
the V1.2 field test kits, when they are available. So, if
you're interested in the API or have a customer that is interested,
please contact Bryan Cox (COOKIE::COX) to become a field test
candidate.
|