Ames Andreas wrote:
Do you have a estimate on a completity of this task? To be honest, I don't know; such an estimation would need to be part of the project itself. Nevertheless I would guess that it's feasible given that TAO has an explicit API to replace its own GIOP stack, see: www.cs.wustl.edu/~schmidt/PDF/pluggable_protocols.pdf
Wow! I didn't know it has API. This simplifies student's time a lot and reduces "time to market". Funny thing is that a student will face ACE vs Boost battle ;-)
I don't know of a similar API in omniORB but at least it supports a 'pluggable transport framework', i.e. you can 'easily' replace the transport layer beneath GIOP (usually IIOP). How this extends to a GIOP replacement would need to be researched separately. FWIW, the CORBA spec explicitly mentions that protocols other than GIOP should be possible (within the abstract CORBA architecture). Another interesting project goal would be to create an API that allows writing compliant objects and/or clients without IDL support. CORBA has the Dynamic Invocation Interface (client side) and the Dynamic Skeleton API (server side). Maybe a student would be interested in trying to create a good generic interface to show off the power of generic programming compared to those more traditional approaches. cheers, aa
-- Alexander Nasonov