vicente.botet wrote:
2. An ORB library to link with. This includes a pretty much complete implementation of CORBA 2.6, including the C++ binding, GIOP/IIOP implementation, valuetypes and abstract interfaces, the Dynamic Invocation and Skeleton interfaces, and almost all of the CORBA messaging specification (async and polling invocations and the policy framework). I have a partial implementation of portable interceptors.
Could you enumerate the features your implementation do not provides? Which one will be mandatory for a first release?
It's pretty complete per CORBA 2.5. Most of what is missing is a few things around the edges. Here's a pretty comprehensive list: 1. No support for Valuetype SendingContextCodeBase, but I think that's primarily a Java thing anyway. 2. No support for the Realtime ORB specification. I wasn't targeting realtime programming, but some of this is useful for non-realtime work too. 3. No implementation of Persistent Requests per the CORBA Messaging specification. I don't know of an ORB that implements this. 4. Some missing stuff around the DynAny interface for valuetypes and valueboxes, since the spec is somewhat unclear and perhaps unimplementable here. 5. There's only a partial client side implemetation of the Portable Interceptors specification. This is where I was last concentrating my work. 6. Several dozen small issues to bring it up to CORBA 2.6. 7. No support for CORBA 3.0 features: local objects, component specification, Object Reference Template stuff. 8. The usual laundry list of known issues & bugs. :)
3. Naming service and a simplistic implementation launching service.
Do you have everything you need already in Boost? With ASIO and the newer Thread library, I think I have everything I need for the ORB library. I have been using ACE up till now. (I actually started this project long before the ACE team started TAO.) If I rewrite the IDL compiler in Wave and Spirit, then I won't need Perl anymore either.
I'm surprised that using ACE currently you don't need nothing more not yet pressent in Boost.
I didn't use much if any of the high level ACE classes. Just the threading, sockets, reactor and/or proactor stuff.
I suppose then that your implementation will contain a lot of infrastructure classes that could be seen as separated libraries. We will see.
Perhaps. Things like the CDR encoding classes could easily be broken out into a separate library. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org