[omniORB] Announcing omniNotify 1.1.BETA

[Robert E. Gruber]

A beta version of omniNotify 1.1 is now available for people to try.  See:

http://www.research.att.com/~ready/omniNotify/index.html

and follow the link to the 1.1 beta download page.

Here is an excerpt from the 1.1.beta release notes:

[omniNotify 1.1.beta RELEASE NOTES]

The current official release is omniNotify 1.0 (the initial release).
We are releasing a beta version of 1.1 of two reasons:
   1. With help from some of our users, we can find problems with the 1.1
      code prior to the official release.  This will make for a more
      stable 1.1 release.
   2. Some people may wish to start prototyping with the fixes or new
      features now rather than later.

** If you choose to use this code, you should be plan on upgrading to the
** official 1.1 release when it is announced.

Release 1.1 depends on omniORB version 3.0.2.

These release notes contain:
   1.  Changes from the last release.
   2.  A new summary of what parts of the CosNotification spec
       are not yet implemented.
   3.  A brief note on our implementation plans.

You may find that earlier release notes provide other useful information.

It should be possible to build omniNotify on most of the platforms on
which one can build the omniORB libraries. So far, we have
successfully built omniNotify on:

 * Linux 2.x (x86)/egcs-1.1.2/binutils-2.9.1.0.14/GNU Libc version 2
 * Solaris 2.{5,6}/ Sun SparcCompiler C++ version 4.2
 * SGI Irix 6.x/SGI C++ compiler 7.2
 * HP-UP 11.0 / aCC

Note that porting to Windows NT is on our list of things to do.  If
you would like to help, you might consider sending us a tip on
where to find portable C++ classes for doing date/time processing for
both Unix and Windows.  We need to be able to parse strings into
times, format times as strings, and so on, dealing with time zone and
daylight savings time, etc.

(omnithread::get_time is a start, but we need more.)

(1) Changes from the Last Release
---------------------------------

(1A) Fixed all known 1.0 bugs:

+ Fixed Bug # 1 :  A small scoping error caused a null
    IOR to be installed in the name service.  Fixed.

* Fixed Bug # 2 :  Changed architecture of channel so that
    offer_change and subscription_change messages
    are sent by threads in special thread pools rather than
    by the thread running the client request which triggered
    the change message.  Added admin properties for controlling
    how many threads are in each pool -- see channel.cfg for
    details.

+ Fixed an unreported bug (channel was incorrectly holding a proxy's
    operation lock across try_pull outcalls).

(1B) Added new feature(s)

+ Added support for non-zero PacingInterval.

(1C) Extended and completely rewrote the examples.

+ The examples now use POA stubs and skeletons
  (the 1.0 examples use BOA).

+ The client code used in the examples is more "real" (more robust,
  more options, ...).  All 16 kinds of channel clients are now
  represented, and a common code base is used, making it easy to
  consistently modify all the examples.

  The advantage of this approach is that the examples should be
  a good starting point for writing real client applications.
  The disadvatage is that these examples can be hard for a novice
  programmer to read.  (We added a file READING_THE_CODE which
  should help some.)

(1D) Reorganized the proxy code -- eliminated some code
  duplication across the 16 kinds of proxy classes implemented
  by the channel.


(2) What Parts of the CosNotification Spec are not yet Implemented?
-------------------------------------------------------------------
We plan to implement the entire spec, except perhaps for the
CosTypedNotify* interfaces.  (We would like feedback on why/whether
we should implement the typed channel interfaces.)

For omniNotify 1.1., in addition to lacking CosTypedNotify* support,
these things are not yet implemented:

+ The channel does not support Persistent Events or Persistent Connections.

+ The channel only supports one ordering property, FifoOrdering,
  for the Order and Discard QoS properties.

+ The channel does not support Mapping filters.

+ There is only partial wildcard support; see 1.0 release notes.