-----Original Message----- From: boost-bounces@lists.boost.org [mailto:boost-bounces@lists.boost.org] 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