From: Ames Andreas (Andreas.Ames_at_[hidden])
Date: 2007-03-06 05:04:30
> -----Original Message-----
> From: boost-bounces_at_[hidden]
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Alexander Nasonov
> Sent: Monday, March 05, 2007 8:33 PM
> Subject: Re: [boost] asio projects (was: Boost and Google
> Summer of Code2007)
> If the proxy is the only thing an end-user could try, it is probably
> not worth the effort.
Granted, it wouldn't possibly be too challenging. But it would be
a reasonable, assesable target for a time constraint project.
> > * Try to replace the native GIOP stack in TAO or OmniORB
> with the new
> > one and measure performance differences for common usage scenarios
> I like the idea. This would open up a possibility to share asio
> "channel" with other network activities of an application.
> 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:
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.
-- Andreas Ames | Programmer | Comergo GmbH | ames AT avaya DOT com Sitz der Gesellschaft: Stuttgart Registergericht: Amtsgericht Stuttgart - HRB 22107 Geschäftsführer: Andreas von Meyer zu Knonow, Udo Bühler, Thomas Kreikemeier
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk