Re: _narrow() patch to CORBA::ORBit dropped?

[Owen Taylor <otaylor redhat com>]

Huw Rogers <count0 building2 co jp> writes:

> I am thinking of forking orbit-perl and creating a project on
> sourceforge for it, so we can get more done.

OK, I guess I should finally respond here :-)

As you all have guessed by now, I have very little time
to work on side projects like orbit-perl these days,
and even if I did have such time, orbit-perl isn't
high on the list of things I want to work on.

A fork of ORBit-Perl seems counter-productive to me
since I'm not going to be maintaining the other side
of the fork.

If there are a couple of people interested in working on 
orbit-perl, I'd be happy to get them access to GNOME
CVS, make them the owners of the mailing list,
and get project web page on gnome.org going with 
auto-update from CVS.

To give a little idea of where orbit-perl comes from,
and what I'd hope would be continued in the future:

 * The first goal of my CORBA bindings was to be
   really easy to use fom Perl. Things like:
 
   - No stubs/skeletons or idl compiler. 
     (The original thought was that it was best to u
     se a interface respository, but after discovering 
     that to be a nightmare in practice with CORBA::MICO,
     I went with the load-the-idl-files-directly
     approach for CORBA::ORbit)

   - Implementing servers by simply derivation
     from the right (magically autogenerated) 
     base class.

   - Enumerations mapped to strings rather than
     constants.

   Are all meant to do that. While there is certainly 
   inspiration in the binding from the C++ bindings,
   it's meant to be very Perl-like, and feel as fun to 
   program with as Perl normally is.

 * the code in orbit-perl is meant to be:

   - Robust.. whatever the other end does

   - "Nice" ... not necessarily well commented (I'm
     not good at that), but well structured and
     tidy. (idl.c being the  glaring exception.)

     Having done two CORBA/Perl bindings previously
     I had a pretty good sense of how it should
     fit together going in, and then did a fair
     bit of clean up and reorganization as I 
     went along.

   - But, only as nice as is possible. The code
     goes as deep as necessary into Perl internals 
     to make a nice Perl interface. (A "bad habit" picked 
     up from looking at Ken Albanowski's Perl-Gtk.)

Regards,
                                        Owen