1. Introduction
    1.1. Project/Component Working Name:
	 Obsolete and/or removal of disparaged librac
    1.2. Name of Document Author/Supplier:
	 Author:  David R
    1.3  Date of This Document:
	15 June, 2005
4. Technical Description
Obsolete and/or removal of disparaged librac
============================================

Supercedes <a href="../../1992/059/">1992/059 Remote Asynchronous Call</A>

The librac(3LIB)/rpc_rac(3RAC) interfaces are designed to
allow an RPC client to make asynchronous calls to a server. The
library contains 4 unique functions:
	rac_drop
	rac_poll
	rac_recv
	rac_send
as well as alternative implementations of a number of libnsl
RPC interfaces. Some are simply duplications of code and differ
only in code style or inadvertent divergence.

Problem
=======
The current code base for this library is effectively dead code or
unnecessary duplication. The only changes to the code has been due to
unrelated projects doing general consolidation wide changes.  Continued
maintainence is of little value. Google searches as well as queries to
the ambassadors find no usage other than the republishing of the
Solaris man pages.  Historically, the last seemingly knowledgeable
opinion of the code was by Carl S who indicated that it was a
kludge for some Solaris transition that was long forgotten. Searches 
show that this library first appeared in Solaris 2.1, and
I could find no evidence of it existing in 4.1.4, SVR4, or SVR3, making
the transition claims questionable.  The libnsl RPC code has been
multi-threaded since 2.4.

The rpc_rac(3RAC) man page contains the following warning:

WARNINGS
     The RAC interface is not the recommended interface for  hav-
     ing  multiple RPC requests outstanding. The preferred method
     of accomplishing this in the Solaris environment is  to  use
     synchronous  RPC  calls  with threads.  The RAC interface is
     provided as a service to developers  interested  in  porting
     RPC  applications to Solaris 2.0. Use of this interface will
     degrade the performance of normal synchronous RPC calls (see
     rpc_clnt_calls(3NSL)). For these reasons, use of this inter-
     face is disparaged.

Ignoring the poor english usage of disparaged, this appears to be
strong language discouraging use.

Opinion requested
=================

1) Is the man page's use of the word "disparaged" constitute
   public notification that these interfaces are "Obsolete"?
2) If the four interfaces are not Obsolete, this case proposes
   to declare them Obsolete.
3) If the four interfaces are Obsolete, the case proposes to
   remove them in the next minor release.


---------------------------------------

Joe has noted that there *is* an early ARC case on this:

	<a href="../1992-059/">1992/059 Remote Asynchronous Call</A>

The opinion and case history shows that the committee was
not particularly happy with it, but approved it:

"This interface is approved as a committed interface.

It may be introduced as such in a minor release.

Its use, however, is disparaged."

I don't know how to translate committed/disparaged into
current taxonomy. It could be argued that this is similar
to other cases that started out as Obsolete knowing they
would not persist.

I would be happy if the committee asserted that this was
in fact an Obsolete interface and I could move to removal.

If not I would like to reference the business justification
in the original case as arguments why it should now be declared
Obsolete.

Of the products that would have been impacted by not shipping librac:

1) SunSelect PC/NFS Toolkit: This product has been EOL'd 5+ years
ago and was rapidly decreasing market share to the point
of having little impact. 

2) SunSoft RPC Toolkit 2.0: This product also has not shipped in
5+ years. 

3) Portable ONC: Selling on ONC RPC has ceased.  The target market
for RAC was DOS and MVS, the former is dead and the latter never
matured.

The market analysis concluded that it was not for the
migration of apps from DOS to Solaris, but the converse to
help allow apps to be ported to DOS. Again a dead OS.

It was stated multiple times that the market was operating systems
that do not support threading. While a notable number in 1992,
the useful number of thread-less OSes left in 2005 is
effectively zero.

	-David R