Ideas for development after omniORB 4
This page contains a few ideas for things that could be worked on for the next major release of omniORB after omniORB 4.0. There are no promises -- this is just a collection of thoughts. The ideas aren't in any particular order.
Internal documentation, clean-up
On the whole, there is little documentation about how omniORB is structured on the inside. In places it is over-confusing, too. A useful starting point to getting new features going would be do more completely document the internal structure, and clean up areas that are confusing.
Objects by value
Doing the chunked marshalling efficiently is the tricky bit. The C++ mapping would be tedious to implement. The best thing is probably to implement the chunked marshalling and the Python mapping first, since the Python mapping is much simpler.
Asynchronous message invocation
Implementing it with threads would be relatively easy. A version without threads would be more work, but would make it much more efficient for some applications.
Clean up the omniidl C++ back-end
The C++ back-end is currently over complex, and doesn't factor out the bits that deal with the C++ mapping, and the bits that relate to omniORB's implementation of it. Cleaning it all up would make it easier to implement new things (like OBV and AMI).
More configurable feature set
Make it possible to cut out bits of the ORB that you don't need for your application. This is important for small embedded platforms. One possibility is to split it into a lot more shared libraries. The disadvantage of that is that each shared library involves some overhead (quite a lot on e.g. Linux), and that you have to jump through hoops to avoid dependencies between the libraries. It's probably best to just be able to miss out some of the code, controlled by some sort of configuration interface.
Inefficient compared to omniORB's native interceptor interfaces, but portability is good.
Support local interfaces properly, so it's less effort to implement things like portable interceptors.
A full security service would be a nice thing to have. Doing it right will be really hard, and requires someone who understands the issues very well.
Standards compliance audit
It would be great if someone trawled through all the CORBA specifications, checking that omniORB adhered to the standard everywhere.
There are a small number of known non-compliance points. One example is the C++ mapping where RefCountServantBase has been removed. This can't be done in omniORB 4.0.x since it would break binary compatibility.
Similarly, it would be good to go over the source checking for security issues like buffer overflows, etc.
Totally re-work the build process
Autoconf and make really aren't pleasant things to work with. It must be possible to do better than that. I have great hopes for [http://scons.sourceforge.net/ SCons] as a make replacement, but I don't think it's quite ready yet. I'm sure it can't be that hard to do an autoconf equivalent in Python that avoids all the M4 macro and portable shell nastiness.