From: Jonathan Biggar (jon_at_[hidden])
Date: 2008-04-02 22:05:45
>> 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
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_at_[hidden] jon_at_[hidden]
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk