Re: [boost] asio projects (was: Boost and Google Summer of Code 2007)

From: Ames Andreas (Andreas.Ames_at_[hidden])
Date: 2007-03-05 08:26:20

> -----Original Message-----
> From: boost-bounces_at_[hidden] 
> [mailto:boost-bounces_at_[hidden]] On Behalf Of Alexander Nasonov
> Sent: Saturday, March 03, 2007 11:49 PM
> Subject: [boost] asio projects (was: Boost and Google Summer 
> of Code 2007)
> 
> In my opinion, the second project is too big for one student.  I
> don't know much about ORB but CORBA standards assume that language
> binding code is generated from IDL. This means that a student should
> first implement a parser (or use existing license compatible parser)
> and a code generator.
> There is another approach for server side. Use Boost.Langbinding
> syntax instead of IDL but this already if big enough for a separate
> project.
> 
> So, I would spent time on libhttp rather than on these projects.

I beg to differ, at least somehow.  Although I'm with you, that a
whole ORB implementation would not even remotely be feasible, I think
a more constraint approach could be both interesting and useful.

Would it be possible to rephrase that proposal to sth. like:

'Implement GIOP 1.2 on top of asio'?

It would probably be most natural to concentrate on the asynchronous
flavours of CORBA:

* AMI on the client side (it's in the offical CORBA specs)

* AMH for the server side (it's a proposal by Douglas Schmidt and
  implemented in TAO, see www.cs.wustl.edu/~schmidt/PDF/AMH.pdf for
  example)

Both flavours shouldn't differ on the protocol level from the normal
synchronous approach but most probably they will affect the API layer.

Some further points may be important:

* Nicely separate layers 7 (GIOP primitives) and 6 (CDR)

* Use TAO, OmniORB and/or a Java ORB (JacORB or the Sun ORB) to test
  interoperability

* Provide an API to enable tampering with other protocol
  implementations (this would include the ability to customise the
  stack down to the bits)

* Provide backwards compatibility with GIOP 1.1 and 1.0

As a possible outcome/proof of concept I could imagine the following
(in ascending order of complexity):

* Provide a transparent GIOP proxy, e.g. for logging the traffic
  between two ORBs

* Try to replace the native GIOP stack in TAO or OmniORB with the new
  one and measure performance differences for common usage scenarios

* Provide python bindings for the mentioned tamoering API

cheers,

aa

-- 
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