Stefan Seefeld wrote:
Jeff Garland wrote:
Alexander Nasonov wrote:
Ames Andreas wrote:
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. I've added a note to the Wiki to this effect -- hopefully warning students away. I see no way that this project is feasible within the time constraints of an SoC project, so it's unlikely that the mentoring team will approve it. The scope would need to be much more limited and defined.
Out of curiosity: What's the relationship between an ORB and boost.org, and why would boost.org want to have its own ?
Good question. Some would probably like to have an ORB solution based on Boost because it would be 'lighter weight' than an ACE/TAO solution. The problem I see is that there's alot of stuff needed to use an ORB (like an IDL compiler) that Boost won't have. So, for a long time you'd wind up with ACE/TAO and Boost. A project that would align more closely with the Boost mission would be a redo of the CORBA binding (it's awful) for C++ using TR1 and other modern C++. This might be more of a design and prototype project that would require both Boost (for things like smart ptrs) and TAO. That's probably too big a project for SoC, but it would be working with a current well defined interface. And there wouldn't be any illusion that it would be going into Boost right away...although that makes is less attractive as a Boost project. Jeff