Document: Systems Management: Common Management Facilities (Draft 0.6)

Change Number: HP 02

Source: Hewlett-Packard

Title: Perl Binding

Qualifier: Technical, Major

Rationale:

  The command line interface provides a way for developers and
  end-user system administrators to implement clients and server
  methods in shell (or other interpreted languages).  It unfortunately
  has several drawbacks, notably that a script process must be run for
  each method invocation, the server methods must manage state between
  invocations, and the fact that external commands are used to process
  arguments and make calls leads to problems due to limits on argument
  length or the use of stdin/stdout for inter-process data
  communications.  Also, there is the problem that shell scripts of
  any complexity are tricky to write and maintain.

  Perl is an efficient language for many programming tasks and has
  become the language of choice for a growing number of system
  administrators.  The most recent version (version 5.0) is a fully
  object-oriented language which makes it straightforward for use in
  writing both clients and servers.  This chapter specifies a perl
  binding for IDL.

  Unlike the shell binding, the perl binding allows the server
  developer to write the implementations of all of the methods of an
  IDL interface in a single program.  In fact, a single process may
  serve any number of objects, each having a potentially different
  interface.  Calls to methods on each of these objects may occur in
  any order and may be interleaved.  In fact, calls may come in while
  the process is awaiting a reply from another server.  This fact
  allows the use of callbacks in which a server can request
  information from the client while processing the call or can notify
  the client of events after the call has terminated.  Finally, since
  a perl process is a full CORBA citizen and can talk and listen over
  standard communications channels such as tcp sockets, it can fully
  interact with clients and servers written in other languages.

  It is our intention to submit this to OMG as a proposal for the
  standard idl binding for perl.
  

Change:

  Add the following chapter after the Command Line Interface (chapter
  4, p. 109):

Chapter X:  Perl Binding

Perl is an efficient language for many programming tasks and has
become the language of choice for a growing number of system
administrators.  The most recent version (version 5.0) is a fully
object-oriented language which makes it straightforward for use in
writing both clients and servers.  This chapter specifies a perl
binding for IDL.

Unlike the shell binding, the perl binding allows the server
developer to write the implementations of all of the methods of an
IDL interface in a single program.  In fact, a single process may
serve any number of objects, each having a potentially different
interface.  Calls to methods on each of these objects may occur in
any order and may be interleaved.  In fact, calls may come in while
the process is awaiting a reply from another server.  This fact
allows the use of callbacks in which a server can request
information from the client while processing the call or can notify
the client of events after the call has terminated.  Finally, since
a perl process is a full CORBA citizen and can talk and listen over
standard communications channels such as tcp sockets, it can fully
interact with clients and servers written in other languages.

This chapter specifies the API for the programmer implementing a
client or server.  It does not specify internal details, nor does it
specify the wire format for calls.  The current version of perl
(version 5.0) is assumed.  A familiarity with this version of perl as
well as CORBA is also assumed.

X.1 Example

A simple, but extended, example will give the flavor of the binding.
We will consider the IDL specification

   interface Foo
   {
      exception E
      {
        string s;
      };

      typedef sequence<string> List;

      long m1(in double a, out List b, inout string c)
         raises (E);
      boolean m2(in Foo me);
   };

There are two ways to proceed, either of which may be chosen
independently by the client and server.

The first way presumes a tool which parses the IDL file and produces a
package "Foo.pm" which implements the client-side static interface and
provides a base class for the server implementation.  Alternatively,
the programmer could produce the (boilerplate) code by hand.

In this case, a client which took the server's object reference as a
string argument would look something like this:

   #!/usr/local/bin/perl

   require(CORBA);
   require(Foo);

   $obj_str = shift;
   $f = _parse Foo($obj_str);

   $env = new CORBA::Environment;
   $c = "test";
   ($res, $b, $c) = $f->m1($env, 12, $c);

   print "An exception occurred!\n"
     if $env->check;

Alternatively, the client could use the dynamic invocation interface:

   #!/usr/local/bin/perl

   require(CORBA);
   require(Foo);

   $obj_str = shift;
   $f = _parse Foo($obj_str);

   $c = "test";
   $env = new CORBA::Environment;

   $op = "Foo::m1";
   $sig = $Foo::_interface{$op};
   $req = new CORBA::Request($f, $op, 12, $c);

   ($res, $b, $c) = $req->invoke($env);

   print "An exception occurred!\n"
     if $env->check;

On the server side, a class would implement the interface:

   require(CORBA);
   require(Foo);
   
   package FooImpl;
   @ISA = ("Foo");

   %_interface = %Foo::_interface;

   sub _initialize
   {
     my $self = shift;

     # $self refers to a hash where we store the data
     # ...initialize...
   }

   sub m1
   {
     my $self = shift;
     my $env = shift;
     my ($a, $c) = @_;

     my ($res, $b);

     # ...compute $res, $b, and the new $c

     if (...) {
        $env->raise(new Foo::E("s" => "something happened"));
        return undef;
     } else {
        return ($res, $b, $c);
   }

   sub m2
   {
      my $self = shift;
      my $env = shift;
      my ($him) = @_;

      my $env = new CORBA::Environment;
      my $res = $him->m1($env, 3, "a string");
      return !$env->check;
   }

and the server proper is simply

   #!/usr/local/bin/perl

   require(CORBA);
   require(Foo);
   require(FooImpl);

   &CORBA::init_server;

   $the_foo = new Foo;

   # If we had a registry, we could pass the reference to it,
   # but we'll just print it out instead:
   $obj_str = $the_foo->_to_string;
   print "$obj_str\n";

   &CORBA::server_listen;

A client can set up to allow callbacks during a call:

   #!/usr/local/bin/perl

   require(CORBA);
   require(Foo);
   require(FooImpl)

   &CORBA::init_server;

   $my_foo = new Foo;

   $obj_str = shift;
   $his_foo = _parse Foo($obj_str);

   $env = new CORBA::Environment;
   $res = $his_foo->m2($env, $my_foo);

   print "An exception occurred!\n"
     if $env->check;

This will call the server's foo's m2 method which is implemented above
to call its argument's (in this case, the client's) m1 method.

If the Foo package is not present, things are similar, except that on
the client side the dynamic invocation interface must be used, and on
the server side the FooImpl class must inherit directly from
CORBA::Object, the Foo::E class must be defined, and the full
interface must be spelled out:

   package FooImpl;
   @ISA = ("CORBA::Object");

   {
     package Foo::E;
     @ISA = ("CORBA::Struct");

     $_tc = &CORBA::Struct_tc("Foo::E", ["s", $CORBA::String_tc]);
   }

   %interface =
   (
     "Foo::m1" => [$CORBA::Long_tc,                  # return type
                   [$Foo::E::_tc],                   # exceptions
                   ["in", $CORBA::Double_tc, "a"],
                   ["out", &CORBA::Sequence_tc($CORBA::String_tc), "b"],
                   ["inout", &CORBA::String_tc, "c"]],
     "Foo::m2" => [$CORBA::Boolean_tc,               # return type
                   undef,                            # no exceptions
                   ["in", $CORBA::Object_tc, "me"]];
                
   );

Here, since the Foo class doesn't exist, the best we can do is say
that m2 takes a general object reference.  And, of course, the
FooImpl::m2 method will have to be changed to use the dynamic
invocation interface.

X.2 The CORBA Package

The core functionality of the system is kept in the CORBA package,
which each script should require:

    require(CORBA);

X.3 Typecodes

The internal representation (and wire representation, which may be
different) for typecodes is opaque to the programmer.  The programmer
refers to the typecodes for scalar types via the variables:

   $CORBA::String_tc
   $CORBA::Boolean_tc
   $CORBA::Octet_tc
   $CORBA::Char_tc
   $CORBA::Short_tc
   $CORBA::Long_tc
   $CORBA::UShort_tc
   $CORBA::ULong_tc
   $CORBA::Float_tc
   $CORBA::Double_tc
   $CORBA::Any_tc
   $CORBA::Typecode_tc

The typecode used when there is no value is $CORBA::Void_tc, which is
undef.

Typecodes for arrays, sequences, structures, user exceptions, object
references, enums, unions are built up:

   &CORBA::Array_tc( $len, $elt_tc );
   &CORBA::Sequence_tc( $elt_tc );
   &CORBA::Struct_tc( $name, [ $e1_name, $e1_tc ], [ $e2_name, $e2_tc ],...);
   &CORBA::Exception_tc( $name, [ $e1_name, $e1_tc ], [ $e2_name, $e2_tc 
],...);
   &CORBA::Object_tc( $uuid );
   &CORBA::Enum_tc( $name, $v1, $v2, ...);
   &CORBA::Union_tc( $name, $switch_tc, $default_name, $default_tc,
                     [ $label_1, $name_1, $tc_1 ],
                     [ $label_2, $name_2, $tc_2 ],... );
      
The first ($name) arguments to Struct_tc, Exception_tc, Object_tc,
Enum_tc, and Union_tc are all fully qualified type names.  The rest of
the strings (specifying fields and enum values) are unqualified.

A special case occurs when a structure contains a sequence which
contains the enclosing structure, as

   struct S
   {
      sequence<S> seq;
   };

For this case, we use

   &CORBA::Recursive_seq( $level );

to represent a sequence which is identical to the $level'th enclosing
sequence.  The example has typecode:

   &CORBA::Struct_tc("S",
       ["seq",
        &CORBA::Sequence_tc(&CORBA::Struct_tc("S",
                               ["seq",
                                &CORBA::Recursive_seq(1)]))]);

This is extremely messy, but fortunately, the programmer should rarely
have to construct typecodes by hand like this.  The generated stubs
should do this automatically, and it should only be necessary to say

   $S::_tc

to get S's typecode.  This holds for any structure, exception, enum,
union, or object reference as well as any named array or sequence
type.  

X.4 Data Structure Mapping

X.4.1 Scalars

Booleans, octets, shorts, longs, floats, doubles, strings, and enums
are all mapped onto perl scalars, which are passed by value.  The
value of an enum is kept as a string.  Note that no distinction is
made between the various numeric types or between numeric types and
strings.  Care must therefore be taken when passing across an
interface that the value being passed is interpretable according to
the required typecode.

When marshaling boolean values, the normal perl definitions of what
constitutes true and false are followed.  The canonical values are 1
and undef.

X.4.2 Arrays and Sequences

Array and sequence types are mapped onto perl arrays, which are passed
by reference.  Note that perl does not require that arrays remain at
fixed length, nor does it require that all elements have the same
type.  Care must therefore be taken when passing across an interface
that all of the elements must be interpretable according to the
required element typecode.  It is not necessary, however to worry
about the length of the array, as extra elements will be ignored and
null elements of the appropriate type will be supplied if needed.

X.4.3 Structs and Exceptions

Structs and user exceptions are realized as hash tables blessed in
packages which inherit from CORBA::Struct.  They are passed by
reference.  The declaration:

   struct S
   {
     boolean a;
     string b;
   };

Maps into something functionally equivalent to:

   package S;
   @ISA = ("CORBA::Struct");

   $_tc = &CORBA::Structure("S",
                            ["a", $CORBA::Boolean_tc],
                            ["b", $CORBA::String_tc]);

>From CORBA::Struct, it inherits a "new" method which takes a hash
table by value as an argument.  An instance of S could therefore be
created by

   $new_s = new S("b" => "some string", "a" => 1);
                                      
The values are read from the hash table directly

   $str = $new_s->{"b"};

The programmer is free to add other values to the hash table.  These
values will not be marshaled across an interface.  The mapping
reserves keys which begin with "CORBA::".

Note that care must be taken when marshaling across an interface that
the keys map onto values interpretable as the declared types.

System exceptions are mapped onto instances of CORBA::SystemException.
It contains a type, a minor number and a completion status.

    $se = new CORBA::SystemException($type, $min, $cs);
    ($type, $min, $cs) = $se->info;

The type is the string identifying the exception, such as "BAD_PARAM"
or "INV_OBJREF".  The minor number is a number identifying a
particular type of this exception.  It should be marshalable as an
unsigned long, and defaults to zero.  The completion status indicates
whether the caller receiving this exception should treat the call as
having completed.  It takes "YES", "NO", or "MAYBE", and defaults to
"YES". 

X.4.4 Unions

Unions are realized as hash tables blessed in packages which inherit
from CORBA::Union.  From CORBA::Union, they inherit a "new" method
which takes an optional discriminator value and (further optional)
slot value.  For instance, the package mapped from

   union U switch(octet) {
     case 1:
     case 2:
       string s;
     case 3:
       boolean b;
     default:
       float f;
   };

yields an instance as

   $new_u = new U;
   $new_u = new U(2);
   $new_u = new U(1, "a string");

The current state may be obtained (and modified) by

   ($dscm, $val) = $new_u->state;
   ($dscm, $val) = $new_u->state($new_dscm);
   ($dscm, $val) = $new_u->state($new_dscm, $new_val);

The values returned are those following any modification.  The old
values may be undefined when the discriminant is modified.  If the
discriminant is set without the value being set, the appropriate slot
will be undefined.

The programmer may also reference the values directly from the hash
table.  The discriminant is stored under "CORBA::discrim".  Other
values may also be set, although only the discriminant and
corresponding value will marshal across an interface.  Keys of which
begin with "CORBA::" are reserved.

Care must be taken when marshaling across an interface that the
discriminant and associated values can be interpreted as the declared
types.

X.4.5 Object References

Object references are implemented as hash tables blessed in a package
inheriting (ultimately) from CORBA::Object.  When an interface
inherits from other interfaces, the package inherits from the
appropriate packages.

An null object reference to interface I is created by calling

   $new_i = new I;

A reference may be obtained from a string by calling

   $new_i = _parse I($str);

Note that this reference is not guaranteed to actually refer to
anything!  An object reference may be narrowed to a particular
interface by calling _narrow:

   $obj = _parse CORBA::Object($str);
   $new_i = _narrow I($obj, $env);

This will actually attempt to communicate with the object and verify that
it does exist and does indeed support the desired interface.  What is
returned it a new reference blessed in I which refers to the same
object.

The stringified form of an object reference may be obtained by calling

   $str = $obj->_to_string;

This string should always be treated as opaque (but reversible by _parse).

The rest of the methods on object references are proxies to remote
calls to the implementation object.  These calls are overridden by
server implementation packages which means that if the implementation
object is local, the implementation method will be called directly.
Method names which begin with underscores are reserved.  (Idl
identifiers cannot begin with underscores, so these are guaranteed not
to clash with user methods).

The programmer may access the hash table directly, although care
should be taken since different implementation packages may also be
using slots.  Keys which begin with "CORBA::" are reserved.

X.4.6 Modules

Modules do not have any special representation.  They merely show up
in the package names of the things they contain.

X.4.7 Anys

Anys are represented as instances of the class CORBA::Any.  They are
constructed by

    $new_any = new Any($val, $tc);
    $new_any = new Any($val);

If the $tc is omitted, the system will endeavor to create one that
looks appropriate.  The programmer should be aware, however that a
non-perl server may not know what to do with a value passed as an Any
with a typecode that it does not recognize.

An Any's state may be queried by

   ($val, $tc) = $any->state;

The state may not be changed (although the state of the value it
refers to may).  If you want a new Any, create one.

When an interface calls for an any parameter and the provided value is
not an any, the system will coerce the value to an any.  When an Any
is provided for an argument which is not an Any, the system will use
the Any's value.  On the server side, an argument to a parameter
declared as an any will always be realized as an Any.  Similarly when
an Any is provided for an argument which is not declared as an Any,
the Any's value is marshaled, so a server will not receive an Any
unless it is expecting one.  Note, however, that any calls on local
instances do not go through this mechanism, so a robust server which
is expecting local calls which may rely on these coersions should be
implemented with robust mechanisms which ensure that the parameter is
correct:

     $any_arg = CORBA::Any($any_arg)
       unless ref($any_arg) eq "CORBA::Any";

     $nonany_arg = $nonany_arg->state
       if ref($nonany_arg) eq "CORBA::Any";

X.5 Environments

Environments are instances of CORBA::Environment.  They are passed as
parameters to methods and "_narrow" calls, and are primarily used for
reporting exceptional conditions.  The main methods supported by
environments are

   $env = new CORBA::Environment;
   $env->clear;                    # clear any exception
   $exception = $env->check;       # return the contained exception,
				   #   if any
   $env->raise($exception);        # set the exception

Other methods may be added by particular implementations.  When a call
passes across an interface, the exception from the environment passed
in by the caller is not marshaled.  When the call returns, any
exception is marshaled back.

Attributes are also implemented by functions in the implementation or
object reference package.  A single function with the attribute's name
implements both the get and set requests.  (There is no set request
if the attribute is declared readonly.) The get request takes an
environment and returns the value.  The set request takes an
environment and a new value.  The value returned by a set request is
ignored when marshaling across an interface, but the method may feel
free to return the new value unconditionally.  A common implementation
of

    attribute string att;
    readonly attribute long ro_att;

might be

    sub att
    {
      my $self = shift;
      my $env = shift;
      my $num_args = scalar(@_);

      $self->{"att"} = shift
         if $num_args;
      return $self->{"att"};
    };

    sub ro_att;
    {
      my $self = shift;
      my $env = shift;
      return $self->{"ro_att"};
    }

X.6 Calling Convention

Methods are realized by functions in the implementation or object
reference package.  They take as arguments the object on which the
method is being invoked, the environment (which may be undefined), and
the in and in-out parameters in order.

If there is an exception, it is set in the environment and the method
should return undef.  Any actual returned value are ignored if the
call was across an interface.  (If it was local, they may still have
effect, although technically this violates the contract specified by
the interface.)  If there is no exception, the method returns the
return value (if any) followed by any out and in-out parameters in
order.

All parameters and return values are passed by value, although some of
the values (which are all scalar) may be references to arrays or hash
tables. 

If the call is local, the environment may be undefined or may already
contain an exception.  A careful method will therefore start

    my $self = shift;
    my $env = shift;
    $env->clear if $env;

or

    my $self = shift;
    my $env = shift || new CORBA::Environment;
    $env->clear;

X.7 Dynamic Invocation

Dynamic invocation is accomplished by means of the CORBA::Request
class.  Requests are constructed by

    $req = new CORBA::Request($obj, $op, $sig, @args);

The args are the in and in-out values as they would be specified to a
method invocation.  This creates a reference to a blessed hash table
with (at least) the following entries:

    {
      "obj"  => $obj,
      "op"   => $op,
      "sig"  => $sig,
      "args" => \@args,
    }

These entries may be modified after the request is created, as by

    $req->{"args"} = [12, $x, "foo"];
    $req->{"op"} = "Bar::mumble";

A request is invoked by

   ($val, @outs) = $req->invoke($env);

If the request is ill-formed, a CORBA::SystemException("BAD_PARAM")
exception will be raised.

For a dynamic request to get or set an attribute, the fully qualified
operation names are "${interface}::_get_${attribute}" and
"${interface}::_set_${attribute}".

X.8 Stub Packages

The stub package implements the object reference.  It serves as both a
proxy for remote instances and as a base class for implementation
packages.  It should be generated by an idl compiler.

The details of the stub may vary from implementation to
implementation, but the following minimum may be expected.

    o The stub will inherit from the stubs for any parent interfaces.
      If there are no parents, it will inherit from CORBA::Object.

    o The stub will register itself by calling

         &CORBA::register_interface($uuid, $pkg_name);

    o The stub will support its typecode by both $I::_tc and &I::_tc.

    o The stub will provide %I::_interface, which is a mapping from
      fully qualified operation names to signatures of the form

         [ $return_tc,
          [ $exception1,...],
          [ $direction1, $tc1, $name1 ],
          [ $direction2, $tc2, $name2 ],...]

      The return typecode and the exception array may be undefined.
      The direction should be one of "in", "out", or "inout".

      This map must include all of the methods supported by the
      interface, even those supported through inheritance.  An easy
      way to handle this is to include the parents %_interface:

         package A;
         @ISA = ("B", "C");
         %_interface = ( %B::_interface, %C::_interface,
                         "A::method" => ... );

      The %_interface also maps fully qualified attribute names to

         ["attribue", $tc]

      or

         ["attribute", $tc, "readonly"]


    o The stub will provide %I::_methods, which is a mapping from bare
      method and attribute names to fully qualified names.  This need
      only be done for those methods declared in this interface.

    o If there is any initialization to be done, the stub may provide
      an _initialize method.  This will be called in depth-first
      sequence when an instance is created by new I (or any subclass).
      It is guaranteed to be called only once per instance.  If an
      instance of exactly this class is created, _initialize will
      receive the parameters to "new".

X.9 Implementation Objects

An implementation object is an instance of a user-written package
which inherits from the stub package corresponding to its interface.
An implementation package may also inherit from other implementation
packages (and, perhaps, other packages).

The implementation package contains the actual methods which implement
the behavior, written to follow the conventions described in X.6.  The
instance is a hash table, and the package may use it to store the
object's state.  Keys which begin with "CORBA::" are reserved.

If the state requires initialization, the package may provide an
_initialize method.  This will be called in depth-first sequence when
an instance is created by "new" of this package or any subclass.  It
is guaranteed to be called only once per instance.  If an instance of
exactly this package is created, _initialize will receive the
parameters to "new".

Every instance which is visible to the outside world has at least one
identity.  This identity is a universally unique identifier (UUID)
combined with a server identity (see X.11).  The identity may be
queried and set explicitly by

    ($obj_id, $serv_id, $dom) = $obj->_identity;
    ($obj_id, $serv_id, $dom) = $obj->_identity($new_oid);
    ($obj_id, $serv_id, $dom) = $obj->_identity($new_oid, $new_sid);
    ($obj_id, $serv_id, $dom) = $obj->_identity($new_oid, $new_sid, $new_dom);

The values returned follow any modifications.  If a new server
identity is specified, it is created, but it does not become the
primary identity.  It is, of course, an error for there to be two
instances at the same time with the same UUID.

The function

   $uuid = &CORBA::uuid;

returns a new universally unique identifier.  

Normally, identities are not created explicitly.  They are generated
as needed when an instance is marshaled or stringified.  A programmer
may, however, wish to say that a particular instance is, in fact, the
current embodiment of one or more prior instances for whom references
may still be floating out in the world.

X.10 Server Startup and Shutdown

Server startup consists of two parts.  The call

   &CORBA::init_server

tells the system that the process is expecting to receive incoming
calls.  Object references passed out or stringified before this call
may have incomplete location information.  Note that this call is
necessary for clients who expect to receive callbacks.

The actual listen loop is entered by

  &CORBA::server_listen

The process also listens for incoming calls when it is waiting for a
reply to an outgoing call.  That is, it listens for both calls and
replies, which may interleave in any order.  If a reply comes in for a
call which is not the most recent, the results must be saved away so
that the stack is unwound properly.

The server is shutdown by calling

  &CORBA::stop_server

This causes an explicit CORBA::server_listen to exit.  If there are
any pending calls, they return with a
CORBA::SystemException("TRANSIENT").

X.11 Server Identity

Every server has at least one identity, which is marshaled as part of
the object reference for all of the objects whose implementations
reside within it.  This identity is composed of two parts: a
universally unique identifier (UUID) and a (possibly empty) locator
domain.  Generally, neither of these need to be specified, and the
system will generate them as needed.  The only time when they should
be specified is when the programmer wants to assert that this process
is the new home of objects whose references have already been
distributed.

The following calls manipulate and query the server identity:

    ($serv_id, $dom) = &CORBA::server_id( $new_sid, $new_dom );
    $dom = &CORBA::domain( $new_dom );

where the arguments are optional, and the values returned follow any
modifications.

From: evan@poirot.hpl.hp.com (Evan Kirshenbaum)
Date: Mon, 12 Feb 1996 14:19:59 -0800
Organization: Hewlett-Packard Laboratories
Telephone: (415)857-7572
Fax: (415)852-8137
Www: http://www.hpl.hp.com/personal/Evan_Kirshenbaum/
To: Tim Bunce <Tim.Bunce@ig.co.uk>, perl5-porters@africa.nicoh.com,
        roehrich@cray.com, jerry@dev.tivoli.com
Subject: (Fwd) Re: Perl5 and CORBA
Cc: JackS@slc.com, asherman@world.std.com
Mime-Version: 1.0
Content-Type: text/plain; charset="us-ascii"
Sender: owner-perl5-porters@nicoh.com
List-Name: perl5-porters

> > From: Dean Roehrich <roehrich@cray.com>
> >
> > > From: jerry@dev.tivoli.com (Jerry Frain)
> > >
> > > Dean Roehrich writes:
> > > > May I forward this document to the perl5-porters?
> > > > Who are the authors of this document?
> > >
> > > The original mail message came from "Evan Kirshenbaum
> > > <kirshenbaum@hpl.hp.com>", it was sent to an OMG mailing list.  I
> > > don't believe there's any reason why it can't be redistributed.
>
> > > Attached find a change request to the Common Management Facilities
> > > document which specifies a proposed perl binding for idl.
> > >
> > > It is our intention to submit this to OMG as a proposal for the
> > > standard idl binding for perl.
>
> The document contains some strange syntax and poor style which worries me.

Sorry. I was reasonably new to perl5 when the document was submitted
last February. :-)  The document was also written against a deadline,
so it might not be as clear as might be wished.

> I'm concerned that this should not be submitted to OMG until it has
> carefully studied by others. It's far too important not to be reviewed
> by those who know the language best.

I quite agree.  The submission was made primarily to counter a
proposal for a shell binding for idl by pointing out that it was
possible to provide a way to specify CORBA processes in a much richer
language with which system managers could be assumed to be familiar.

It was acknowledged at the meeting that it was much too premature for
X/Open to pursue something like this and that it should proceed
through OMG where it would receive higher scrutiny by multiple
companies.

> It also specifies some semantics (such as exception handling) which should
> certainly be discussed first.

Discussion is good.

> Who is the author? (Evan?)

Yup.  If you're asking for a resume, I am one of the principal
designers/implementors of the ORB research platform at HP labs.  I
have a considerable background in perl, although at the time I wrote
the document, I was reasonably new (as was most everybody) to perl 5.
I have not done any work on perl internals, though.

> What is the current status of the work? Is it financed?

It is currently in a bit of limbo.  The document you have was written
at the beginning of last year, but it was mostly a side activity of
mine (although there was interest in the work).  We are funded to
investigate bindings for various languages, and it is quite likely
that we will be looking at perl this year (especially if, as it
appears, there is interest in the wider community).

> Has anything been submitted to OMG? If so can it be changed easily?

Nothing has been submitted to OMG (at least by me).  I am very open to
changes.

> Does a working prototype exist? If so, can it be released?

A prototype was written for a large subset.  It was written entirely
in Perl 5.  It used an ad hoc wire format, as IIOP was still in the
process of development.  There was no idl compiler that spit out the
perl classes.

I am hesitant to release the prototype as (a) the coding is doubtless
not exemplary, (b) I haven't really reviewed that code in quite a
while, (c) I'm not sure that I can give it away without also giving
away proprietary details of our ORB implementation, and (d) I'm not
sure that I believe that a Perl to the wire solution is the correct
way to go.

If there is a community-wide effort to put together a specification
for submission to OMG, I would very much like to be involved.

Hope this helps.



----
Evan Kirshenbaum                       +------------------------------------
    HP Laboratories                    |Feeling good about government is like
    1501 Page Mill Road, Building 1U   |looking on the bright side of any
    Palo Alto, CA  94304               |catastrophe.  When you quit looking
                                       |on the bright side, the catastrophe
    kirshenbaum@hpl.hp.com             |is still there.
    (415)857-7572                      |                  P.J. O'Rourke

    http://www.hpl.hp.com/personal/Evan_Kirshenbaum/