Conference cookie::mru

I have a customer (ISV) looking for a programming interface for controlling an
optical jukebox.  Lacking something new in an MRU API, their options look to
be
/dev/cam User Agent or possibly licensing the Media Changer driver.

Anything progress on an MRU API?

Thanks!

Norm Saunders
Fed. Govt. Region Engineering
[Posted by WWW Notes gateway]

	As always, please talk to our Product Manager, Bryan Cox.

	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.