This is to announce the availability of an alpha release of ILU 2.0,
ILU 2.0alpha14. See ftp://ftp.parc.xerox.com/pub/ilu/ilu.html to
download the sources for UNIX or Windows.
The Inter-Language Unification system (ILU) is a multi-language object
interface system. The object interfaces provided by ILU hide
implementation distinctions between different languages, between
different address spaces, and between operating system types. ILU can
be used to build multi-lingual object-oriented libraries ("class
libraries") with well-specified language-independent interfaces. It
can also be used to implement distributed systems. It can also be
used to define and document interfaces between the modules of
non-distributed programs. ILU interfaces can be specified in either
the OMG's IDL language, or in ILU's Interface Specification Language,
which allows extensions to the CORBA spec. Programming languages
supported in 2.0alpha14 are ANSI C, Common Lisp, Java (1.1.x and 1.2),
and Python (through 1.5.x); rough Guile Scheme and C++ support is also
present. Additional ILU support for Perl is freely available from
outside sources. Operating systems supported in 2.0alpha14 are all
Windows platforms with Win32 and WinSock, and all UNIX platforms with
BSD sockets and minimal POSIX compliance, including Linux, Solaris,
AIX, IRIX, and OSF/1. 2.0alpha14 supports interoperability with ONC
RPC services, OMG CORBA services, World Wide Web HTTP services, and
W3C HTTP-NG services. ``Plug-in'' extensibility is provided for RPC
message formats, message transport schemes, URL schemes, accounting
and authorization identity types, threading and event loop processing,
and various other things. An implementation of the IETF's Common
Authentication Technology working group's Generic Security Service
(GSS) is provided, and can be used to wrap client-server connections
in a security context. An XML parser is provided. ILU is provided
free for unrestricted use.
Known bugs are listed in the README file. Despite being an alpha
release, 2.0alpha14 is very stable along a number of dimensions.
Principal areas still under development, and hence unstable, are: the
C++ mapping, the HTTP-NG protocols, and the specific contents of
the ILU profile in the OMG CORBA IOR.
Patches will be appearing in the file
ftp://ftp.parc.xerox.com/pub/ilu/2.0a14/patches.html. Please fetch
this file and apply the patches before attempting to build ILU. See
the beginning of the patch file for information on how to apply
patches.
Changes from 2.0alpha13 to 2.0alpha14
-------------------------------------
* New Type UID Hash Algorithm. This release introduces a documented
algorithm for producing the ILU `type hash' for an ISL type. It's
documented in the ILU manual, in the section entitled "Algorithm
for Generation of Structural-Hash Type IDs". This algorithm will
become the default algorithm for the next release, but the old
algorithm is still the default for this release. You can enable
the new algorithm with the configuration switch
-enable-version-2-type-uids. We recommend that you do this, if
possible. ILU configured with the version 2 type uids will *not*
be on-the-wire compatible with ILU configured with the old type
uids.
* Directives in ISL. The ISL syntax has an experimental directives
concept. Expect changes before this is made final.
* Java support. Supports running ILU and a standard CORBA ORB in
the same address space. Optional support for JNI based native
methods. Support for jdk1.2. Support for Microsoft sdk3.1.
Switchable usage of org.omg.CORBA classes (Java core for jdk1.2 or
provided by ILU for jdk1.1). No more problems with the boot
class path. Configuration process slightly improved.
* Java API changes. Default use of org.omg.CORBA.Object interface
as base type for all ILU stubbed objects. Corba system exceptions
are no longer subclassed; other minor API changes required for
sharing address space with standard ORBs. Most users shouldn't
notice these changes.
* Java serialization support. Most Java classes and interfaces
corresponding to ISL types are now serializable. Among other
things, this allows ILU objects to be passed via `Java RMI'.
Also, a new ILU interface exists which allows transport of
arbitrary Java serializable objects with ILU. Third, a very
experimental `DIRECTIVE-EXPERIMENTAL' mechanism which optionally
allows classes implementing ILU object types to avoid extending
org.omg.CORBA.Object (and optionally, extend java.rmi.Remote).
Also, custom mapping may now be specified in the ISL file using
the `DIRECTIVE-EXPERIMENTAL' keyword.
* Support for Python CORBA mapping. This release includes a
preliminary version of the CORBA mapping for Python. You should
configure ILU with --enable-corba-python-mapping to get this form
of Python support, instead of the "classic" version documented in
the ILU reference manual. See
`http://www.informatik.hu-berlin.de/~loewis/python/pymap.htm' for
more information on this mapping.
* Python has experimental support for passing dictionaries. If
--enable-python-dictionaries is specified during configuration, the
mapping of ISL to Python generated by the stubber will be modified
as follows: If a sequence type has a base type which is a record
type with two fields, `name' and `value', and the type of the
`name' field is an integer or string type, and the name of the
sequence type ends with `"dict"' or `"Dict"', the sequence type
will be mapped to a Python dictionary instead of to a list. The
key value of each item in the dictionary will be the value of the
`name' field of a record value, and the value value of the item
will be the value of the corresponding `value' field of the same
record value. This mapping may change in the future.
* Python `auto-import' of ILU interfaces now enabled by default. In
this release, loading of the Python `ilu' module will cause a call
to `ilu.AutoImport()', with no parameters. This can be defeated
by setting the environment variable
`ILU_PYTHON_DISABLE_AUTOIMPORT' before loading the `ilu' module,
and `ilu.AutoImport' can still be called manually at a later time.
* Lisp "old-style" method names not produced by default. The
default for lisp is to not produce the old-style method names.
Users who need them should specify the
--enable-old-lisp-method-names configuration switch to get them.
--
Bill Janssen <·······@parc.xerox.com> (650) 812-4763 FAX: (650) 812-4777
Xerox Palo Alto Research Center, 3333 Coyote Hill Rd, Palo Alto, CA 94304
URL: ftp://ftp.parc.xerox.com/pub/ilu/misc/janssen.html