RELEASE NOTES
=============

This is omniORB 4.1.6.

See README.unix or README.win32.txt for building instructions.
See the documentation in the doc directory for more information.


Changes since omniORB 4.1.5
---------------------------

 - Bug fixes. See bugfixes-415.xml

 - New clientOpenConnection and serverAcceptConnection interceptors.


Changes since omniORB 4.1.4
---------------------------

 - Bug fixes. See bugfixes-414.xml

 - Support for building with the newest versions of Cygwin.

 - Incoming SSL connections can time out waiting for SSL_accept to complete.

 - Ability to disable longdouble support during compilation.


Changes since omniORB 4.1.3
---------------------------

 - Bug fixes. See bugfixes-413.xml

 - Connection management enhancements and logging improvements.

 - Ability to switch bidirectional mode at run-time.


Changes since omniORB 4.1.2
---------------------------

 - Bug fixes. See bugfixes-412.xml

 - Option to validate UTF-8 string data.

 - New omni_mutex trylock method.

 - New ISO-8859 and Windows code sets.

 - Port to LynxOS.


Changes since omniORB 4.1.1
---------------------------

 - Bug fixes. See bugfixes-411.xml.

 - omniNames Windows service support. See doc/omniNames.pdf.

 - Support for multi-endpoint SSL IORs (using an extremely minimal
   subset of CSIv2).



Changes since omniORB 4.1.0
---------------------------

 - Bug fixes. See bugfixes-410.xml.

 - Documentation updates.

 - Support for new platforms and compilers.

 - New configuration parameters: socketSendBuffer, resetTimeOutOnRetries.

 - New -Wbguard_prefix option to omniidl.

 - Small performance improvements.


Changes since omniORB 4.1.0 release candidate 2
-----------------------------------------------

 - Bug fixes.


Changes since omniORB 4.1.0 release candidate 1
-----------------------------------------------

 - Modified Windows platform files and DLL names. Platforms are now
   x86_win32_vs_*

 - Minor bug fixes.


Changes since omniORB 4.1.0 beta 2
----------------------------------

 - Incompatible change to the clientSendRequest interceptor members.
   Application code using the interceptor will require a small
   modification.

 - Support for insertion / extraction of various types from standard
   iostreams.

 - More comprehensive logging of connection and protocol errors.

 - Experimental omniConnectionMgmt extension.

 - Minor bug fixes.


Changes since omniORB 4.1.0 beta 1
----------------------------------

 - IPv6 support.

     See section 8.6.1 of the omniORB manual for details.

 - New endPointPublish parameter.

     Used for configuring what to publish in IORs. See section 8.6.2
     of the omniORB manual.

 - Minor bug fixes.


Changes since omniORB 4.0.x
---------------------------

 - Objects by value support.

     omniORB now supports the full objects by value specification,
     with the exception of custom valuetypes. See chapter 13 of the
     omniORB manual for information about valuetype in omniORB.

 - Abstract interfaces support.

 - New simpler and more efficient Any implementation.

 - New socket collection implementation.

     Uses poll() on platforms where it is available to avoid limiting
     the number of connections to FD_SETSIZE. Windows specific version
     that better manages the unusual Windows fd_set.

 - New tracing options traceTime and traceInvocationReturns.

     See section 4.2 of the omniORB manual.

 - C++ mapping updated to version 1.1.

     Deprecation of RefCountServantBase; Servant_var template type.

 - Support for local interfaces.

     In particular, ServantManagers and AdapterActivators no longer
     need to be activated in a POA, but can be simple C++ objects. See
     the examples in src/examples/poa/servant_manager.

     Note that to use local interfaces derived from unconstrained
     interfaces, you must compile the idl for the base interfaces
     using the -Wbvirtual_objref -Wbimpl_mapping omniidl flags.



Known issues
------------

This release has the following known issues and omissions:

 - valuetypes supporting local interfaces generate invalid C++. This
   is an issue with the standard C++ mapping.
