I agree with the others, the namespace epics::osi should be well-
recognized within this community, I see no reason to change it.
The namespace "epics::osi" is definitely not well recognized within the
community because I created it last fall on the CVS main trunk. It isn’t in
any released version of the software.
During the design of R3.14 and R3.13 I used "osi" embedded in the global
names of many operating system independent C functions. I needed such
functions earlier because the CA client library was portable almost from the
beginning. At some point during the port of the IOC to other OS "osi" was
removed from many operating systems independent interfaces in favor of
"epics" according to popular decision at an APS meeting. Some C functions
retain "osi" in their names today because I just didn’t have time to change
everything. There were no namespaces at that time; we did not favor using
them because of portability concerns with certain archaic vxWorks compilers.
Those compilers are probably 15 years old; so perhaps namespaces are
appropriate now. With the advent of c++ namespaces in EPICS we must choose
wisely. Perhaps we will decide that putting most functions in an "epics"
namespace is now a good idea. Nevertheless, after some careful thought
perhaps all will conclude that this "epics" namespace would need to be
partitioned, and so one is led to the idea of "epics :: osi" or perhaps
alternatively "epics :: osl" or "epics :: ???" for operating system
independent interfaces. Personally "epics :: osi" does not bother me. I am
suffering from the impression that the APS developers didn’t like the name
"osi" and so I was attempting to find a compromise name using an appropriate
review process.
Thanks for your contemplation,
Jeff
______________________________________________________
Jeffrey O. Hill Email [email protected]
LANL MS H820 Voice 505 665 1831
Los Alamos NM 87545 USA FAX 505 665 5107
Message content: TSPA