CORBA iimplementation for Boost interest?
I've been working on a C++ CORBA implementation for a long time. I've considered making it open source in the past, but I hadn't seen the exact niche for it to fill. Now that Boost 1.35 is out, including ASIO and the new Threads implementation, I'm considering retargeting my implementation to only use boost libraries for underlying services. I'd be quite happy to contribute my implementation to boost, if there's enough interest for me to proceed. So, what do you all think? -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org
I was considering (but lacking time to do it yet) implementing a library wrapper over existing CORBA implementations. Basically trying to get CORBA to a more C++-friendly interface. I don't know if creating a new implementation will be worth the time spent on it, but if you get to do it, I'll be more than willing to collaborate. Considering the interest placed lately in JSON and other Serialization backends, a CORBA backend might be of interest to GSoC students and could be useful for the implementation. David On Tue, Apr 1, 2008 at 5:49 PM, Jonathan Biggar <jon@floorboard.com> wrote:
I've been working on a C++ CORBA implementation for a long time. I've considered making it open source in the past, but I hadn't seen the exact niche for it to fill.
Now that Boost 1.35 is out, including ASIO and the new Threads implementation, I'm considering retargeting my implementation to only use boost libraries for underlying services.
I'd be quite happy to contribute my implementation to boost, if there's enough interest for me to proceed.
So, what do you all think?
-- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
On Tue, 01 Apr 2008 21:25:45 +0200, David Rodríguez Ibeas wrote:
Considering the interest placed lately in JSON and other Serialization backends, a CORBA backend might be of interest to GSoC students and could be useful for the implementation.
Not a CORBA expert (read it is as COBRA (the reptile) for a long time!) but I think a CORBA backend makes no sense for serialization. Instead you might use serialization to marshal the data between distributed C++ components. Sounds crazy enough to work! -- Sohail Somani http://uint32t.blogspot.com
Sohail Somani wrote:
On Tue, 01 Apr 2008 21:25:45 +0200, David Rodríguez Ibeas wrote:
Considering the interest placed lately in JSON and other Serialization backends, a CORBA backend might be of interest to GSoC students and could be useful for the implementation.
Not a CORBA expert (read it is as COBRA (the reptile) for a long time!) but I think a CORBA backend makes no sense for serialization. Instead you might use serialization to marshal the data between distributed C++ components. Sounds crazy enough to work!
But that's exactly how boost.mpi works, isn't it ? Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Tue, 01 Apr 2008 15:40:46 -0400, Stefan Seefeld wrote:
Not a CORBA expert (read it is as COBRA (the reptile) for a long time!) but I think a CORBA backend makes no sense for serialization. Instead you might use serialization to marshal the data between distributed C++ components. Sounds crazy enough to work!
But that's exactly how boost.mpi works, isn't it ?
See? Crazy! In all seriousness though, it seems that they do similar things but my bet is that one is considered more enterprisey. Just did a quick Google, and lookie here: http://www.daimi.au.dk/~pmn/scf00/pro3/images/corba-mpi.gif Enterprisyness is sometimes the difference between MPI and other distributed computing environments. Oh well, keeps us interested, doesn't it? Besides, variety is the spice of life ;-) -- Sohail Somani http://uint32t.blogspot.com
On Tue, Apr 1, 2008 at 1:35 PM, Sohail Somani <sohail@taggedtype.net> wrote:
On Tue, 01 Apr 2008 21:25:45 +0200, David Rodríguez Ibeas wrote:
Considering the interest placed lately in JSON and other Serialization backends, a CORBA backend might be of interest to GSoC students and could be useful for the implementation.
Not a CORBA expert (read it is as COBRA (the reptile) for a long time!) but I think a CORBA backend makes no sense for serialization. Instead you might use serialization to marshal the data between distributed C++ components. Sounds crazy enough to work!
Correct. Further, since CORBA deals with remote objects etc, it requires serialization that is cross platform. e.g. Platform A must always be able to correctly deserialize messages that were serialized by platform B, for all platforms A and B. I believe this not to be the case for Boost.Serialization, but Sohail would clearly know the answer to this. Jon
On Tue, 01 Apr 2008 15:58:45 -0600, Jonathan Franklin wrote:
Further, since CORBA deals with remote objects etc, it requires serialization that is cross platform. e.g. Platform A must always be able to correctly deserialize messages that were serialized by platform B, for all platforms A and B. I believe this not to be the case for Boost.Serialization, but Sohail would clearly know the answer to this.
You can (and I have) done this with Boost Serialization without any problem. The only time when you may have a problem is if you have to load archives from the future :-) -- Sohail Somani http://uint32t.blogspot.com
On Tue, Apr 1, 2008 at 6:08 PM, Sohail Somani <sohail@taggedtype.net> wrote:
On Tue, 01 Apr 2008 15:58:45 -0600, Jonathan Franklin wrote:
Further, since CORBA deals with remote objects etc, it requires serialization that is cross platform. e.g. Platform A must always be able to correctly deserialize messages that were serialized by platform B, for all platforms A and B. I believe this not to be the case for Boost.Serialization, but Sohail would clearly know the answer to this.
You can (and I have) done this with Boost Serialization without any problem. The only time when you may have a problem is if you have to load archives from the future :-)
Then let me recommend the new Gmail Time Service: http://mail.google.com/mail/help/customtime/index.html But seriously, that must be new. It didn't do that the last time I played w/ Boost.Serialization. Progress! Jon
From: "Jonathan Biggar" <jon@biggar.org> Subject: [boost] CORBA iimplementation for Boost interest?
I've been working on a C++ CORBA implementation for a long time. I've considered making it open source in the past, but I hadn't seen the exact niche for it to fill.
Now that Boost 1.35 is out, including ASIO and the new Threads implementation, I'm considering retargeting my implementation to only use boost libraries for underlying services.
I'd be quite happy to contribute my implementation to boost, if there's enough interest for me to proceed.
So, what do you all think?
-- Jon Biggar
Hello, I think that a C++ CORBA implementation is a big deal. In addition a corba implemenation is not very useful without a minimal set of CORBA services. Are you mapping idl files to C++ using a generator? Do you use the standard C++ mapping, or a mapping using more generic C++ techniques? Could you present your current implementation, OS, middleware, ... Could you present a little bit your project, contents, architecture, ... Do you have everything you need already in Boost? Good luck _____________________ Vicente Juan Botet Escriba
vicente.botet wrote:
I think that a C++ CORBA implementation is a big deal. In addition a corba implemenation is not very useful without a minimal set of CORBA services.
I can imagine an experimental new C++ binding to be a worthy summer project. I have been using omniORB (http://omniorb.sourceforge.net/) heavily in the past, and I believe it to be easy enough to apply changes, in particular to its IDL compiler backend (which is written in Python), to generate code for such an alternative language binding. In addition, some of the obvious changes are small and could be applied incrementally. So, technically I don't see any reason not to try it, if someone's up to that task. FWIW, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Tue, Apr 1, 2008 at 2:05 PM, Stefan Seefeld <seefeld@sympatico.ca> wrote:
vicente.botet wrote:
I think that a C++ CORBA implementation is a big deal. In addition a corba implemenation is not very useful without a minimal set of CORBA services.
I agree. You need a minimal ORB impl, which is non-trivial to make usable. You can get away without a NamingService, but not for long. I can imagine an experimental new C++ binding to be a worthy summer
project.
...
So, technically I don't see any reason not to try it, if someone's up to that task.
A new binding would have to be pushed through the OMG. I don't even want to *think* of the can of worms you'll probably open there. I've been wishing for even a semi-rational IDL-C++binding since prior to 00. Jon
Jonathan Franklin wrote:
A new binding would have to be pushed through the OMG.
I am not sure it *has* to. As far as I see it, nothing prevents one from proposing a new mapping. But long before that is needed: * Nothing prevents ORB vendors and open source ORBs to provide support for additional non-standard or proposed bindings. * Nothing prevets boost from supporting open source ORBs as back ends. * Nothing prevents boost from supporting a new binding to old binding adaptors for those unhappy fellows stuck with an old ORB or hard to convince vendor. It may not even need to copy data as CORBA::Sequence has a continious storage requirement similar to std::vector and ownership transfer semantics. CORBA C++ Strings are essentially character buffers. Probably if it is as successfull as we may wish and hope, someone at OMG has got the point and adapted it, and the problem never materialized.
I don't even want to *think* of the can of worms you'll probably open there.
Right!!! But who are you to know before you take the lid off. Maybe it is welcomed by many and get strong support. A proposal based on a boost project or library may have some leverage in the C++ comunity, and in OMG the benifit of neutral ground ;-)
I've been wishing for even a semi-rational IDL-C++binding since prior to 00.
Yes -- you, me and probably anybody else with more than half a brain using C++ and CORBA. -- Bjørn
On Tue, Apr 1, 2008 at 5:17 PM, Bjørn Roald <bjorn@4roald.org> wrote:
Jonathan Franklin wrote:
A new binding would have to be pushed through the OMG.
I am not sure it *has* to. As far as I see it, nothing prevents one from proposing a new mapping. But long before that is needed:
Ultimately, for it to be part of CORBA, it does. * Nothing prevents ORB vendors and open source ORBs to provide support
for additional non-standard or proposed bindings.
Nope. And early on, that's just what ORB vendors did... That's pretty much how IIOP came about.
* Nothing prevets boost from supporting open source ORBs as back ends.
This is a great place to start.
I don't even want to *think* of the can of worms you'll probably open there.
Right!!! But who are you to know before you take the lid off.
I've seen the insides of that can before, and really don't want to take another look. Too scary! :-)
Maybe it is welcomed by many and get strong support. A proposal based on a boost project or library may have some leverage in the C++ comunity, and in OMG the benifit of neutral ground ;-)
With enough interest and momentum, this may be the best way to push it through. Problem is, interest in and momentum behind CORBA is all but gone these days. Perhaps you can bring it back. :-)
I've been wishing for even a semi-rational IDL-C++binding since prior to 00.
Yes -- you, me and probably anybody else with more than half a brain using C++ and CORBA.
Which really begs the question as to why it never got better. Cynically yours, ;-) Jon
Jonathan Franklin skrev:
On Tue, Apr 1, 2008 at 5:17 PM, Bjørn Roald <bjorn@4roald.org> wrote:
Jonathan Franklin wrote:
A new binding would have to be pushed through the OMG.
I am not sure it *has* to. As far as I see it, nothing prevents one from proposing a new mapping. But long before that is needed:
Ultimately, for it to be part of CORBA, it does.
Sure, and that should probably be a goal. But bits of CORBA can be used for many usefull things. A C++ binding that support IIOP and other useful transports come to mind. If it is flexible, powefull, etc. Users may not care much whether it is OMG approved.
* Nothing prevents ORB vendors and open source ORBs to provide support
for additional non-standard or proposed bindings.
Nope.
And early on, that's just what ORB vendors did... That's pretty much how IIOP came about.
right.
* Nothing prevets boost from supporting open source ORBs as back ends.
This is a great place to start.
agree
I don't even want to *think* of the can of worms you'll probably open there.
Right!!! But who are you to know before you take the lid off.
I've seen the insides of that can before, and really don't want to take another look. Too scary! :-)
I would never ask you to do that then!
Maybe it is welcomed by many and get strong support. A proposal based on a boost project or library may have some leverage in the C++ comunity, and in OMG the benifit of neutral ground ;-)
With enough interest and momentum, this may be the best way to push it through. Problem is, interest in and momentum behind CORBA is all but gone these days.
Perhaps you can bring it back. :-)
Well, that is much to much to hope for. I for one do however think much of the de-hype og CORBA is do to the hype of other newer and in many cases much less usefull middleware solutions. CORBA implementations are free these days, so mobody earn much on hyping CORBA any more. Kind of prooves the point of making standards. People can choose their implementation. And they choose the best they can get for less money - surprice... The big time CORBA vendors realized this, dumped CORBA and created as much friction as they could in OMG. Web services and all their assosiated non-standarized propriatory frameworks on the other hand are an eldorado for comercial tie-up these days, and it has been so for some time.
I've been wishing for even a semi-rational IDL-C++binding since prior to 00.
Yes -- you, me and probably anybody else with more than half a brain using C++ and CORBA.
Which really begs the question as to why it never got better.
Good point, pretty much shows that OMG has had their focus elsewhere. -- Bjørn
Jonathan Franklin wrote:
Yes -- you, me and probably anybody else with more than half a brain using C++ and CORBA.
Which really begs the question as to why it never got better.
Being on the inside of OMG shortly after the first C++ binding was adopted, I can tell you it really was a can of worms. There was initially a much more OO proposal that was almost adopted, but a certain member organization (I'll leave it nameless to protect the guilty) insisted that the C++ binding had to be binary link-compatible with the adopted C binding, so we got the messy one we have now. Never mind that the link-compatibility turned out to be more of a pipe-dream than a reality. As far as re-engineering the C++ binding, it will almost certainly have to be done by someone outside the OMG and presented as a completed work. The ORB vendors (probably appropriately) never saw a business case to implement and support a second C++ binding. I'm certainly game to participate in re-engineering the binding, but I think it would be a good idea to get what I can contribute in place as a solid boost library first. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org
On Tue, Apr 1, 2008 at 6:09 PM, Jonathan Biggar <jon@biggar.org> wrote:
As far as re-engineering the C++ binding, it will almost certainly have to be done by someone outside the OMG and presented as a completed work.
I'd be inclined scrap everything but IIOP (even that is debatable), and create something more lightweight, picking and choosing the bits from the CORBA architecture that make sense. Don't bother with the OMG, and make it *not* CORBA (per se). Eventually standardize the wire protocol and language bindings w/ some standards body. And in essence, build something Awesome that people actually *want* to use. Cutting OMG and any sort of CORBA compliance out of the picture, I'd even be willing to help... A lot. :-) Jon
Jonathan Franklin wrote:
On Tue, Apr 1, 2008 at 6:09 PM, Jonathan Biggar <jon@biggar.org> wrote:
As far as re-engineering the C++ binding, it will almost certainly have to be done by someone outside the OMG and presented as a completed work.
I'd be inclined scrap everything but IIOP (even that is debatable), and create something more lightweight, picking and choosing the bits from the CORBA architecture that make sense. Don't bother with the OMG, and make it *not* CORBA (per se). Eventually standardize the wire protocol and language bindings w/ some standards body. And in essence, build something Awesome that people actually *want* to use.
Cutting OMG and any sort of CORBA compliance out of the picture, I'd even be willing to help... A lot. :-)
Well, you can feel that way, but that rather chops my proposal out entirely. I think you're giving CORBA a bad rap. Yes there are klunky parts of the standard (contexts, anyone?), but if you ignore them and redesign the C++ binding, what's left is quite workable. And I think the chances of standardizing a CORBA replacement that is multi-language and multi-platform is pretty much nil. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org
On Tue, Apr 1, 2008 at 9:00 PM, Jonathan Biggar <jon@biggar.org> wrote:
Well, you can feel that way, but that rather chops my proposal out entirely.
Doesn't have to be CORBA. Just OO middleware that's "inspired" by CORBA.
I think you're giving CORBA a bad rap.
This is of course my personal opinion, but I think it deserves the rap that it gets. People stopped using it because it was too complicated (too hard to find good CORBA developers) and clunky.
Yes there are klunky parts of the standard (contexts, anyone?), but if you ignore them and redesign the C++ binding, what's left is quite workable.
I'd redo even the NamingService spec.
And I think the chances of standardizing a CORBA replacement that is multi-language and multi-platform is pretty much nil.
I've never tried to push anything through a standardization process, and have no idea how difficult this is. Of course, do you really need to standardize an OO middleware product that kicks enough butt to become a de facto standard? My gut feeling is that changing CORBA in any but superficial ways will be impossible. Then you're stuck w/ Jonathan's ORB. Maybe that's not a Bad Thing (TM). Incidentally, have you looked at ICE? Jon
Jonathan Franklin wrote:
Well, you can feel that way, but that rather chops my proposal out entirely.
Doesn't have to be CORBA. Just OO middleware that's "inspired" by CORBA.
You're talking about a couple of orders of magnitude more work to get something going, compared to the pretty much complete implementation I'm offering.
I think you're giving CORBA a bad rap.
This is of course my personal opinion, but I think it deserves the rap that it gets. People stopped using it because it was too complicated (too hard to find good CORBA developers) and clunky.
People need to recognize that developing good transparent OO invocation middleware is far from trivial. It's a complex problem, and complex problems need relatively complex solutions. Sure, there's appeal to the idea of starting over to get it "right", but how much better will it really be and how long will it take, and will you get the feedback from the people who have been there and done that?
Yes there are klunky parts of the standard (contexts, anyone?), but if you ignore them and redesign the C++ binding, what's left is quite workable.
I'd redo even the NamingService spec.
Again, you can point to klunky parts. I can also explain the history of why it got that way, and I'd bet you'd find the rationale understandable. Many things, like the NameService spec, can be wrapped in a utility class that makes it quite easy to use and avoids the klunkiness.
And I think the chances of standardizing a CORBA replacement that is multi-language and multi-platform is pretty much nil.
I've never tried to push anything through a standardization process, and have no idea how difficult this is. Of course, do you really need to standardize an OO middleware product that kicks enough butt to become a de facto standard?
No, but don't trivialize how long it takes to get to butt-kicking stage. :)
My gut feeling is that changing CORBA in any but superficial ways will be impossible. Then you're stuck w/ Jonathan's ORB. Maybe that's not a Bad Thing (TM).
Incidentally, have you looked at ICE?
Yes. In fact I know one of the developers quite well. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org
On Tue, Apr 1, 2008 at 9:38 PM, Jonathan Biggar <jon@biggar.org> wrote:
Doesn't have to be CORBA. Just OO middleware that's "inspired" by CORBA.
You're talking about a couple of orders of magnitude more work to get something going, compared to the pretty much complete implementation I'm offering.
Okay.
People need to recognize that developing good transparent OO invocation middleware is far from trivial. It's a complex problem, and complex problems need relatively complex solutions.
You're preaching to the choir. I worked on a CORBA-based middleware product for *many* years. Even contributed in very small ways (bug patches) to TAO. Though I haven't given up hope on building something that is simple and elegant to use. Many things, like the NameService spec, can be wrapped in a utility
class that makes it quite easy to use and avoids the klunkiness.
Been there too. I just don't want another "pretty" wrapper around something I find fundamentally flawed. But that's my opinion, and is not to say that others won't find it useful, or desirable. No, but don't trivialize how long it takes to get to butt-kicking stage. :) I understand the scope and magnitude. I also posit that if you build something on top of CORBA, you'll never get to the butt-kicking stage. Just my opinion from having squandered years of my life in the attempt. .
My gut feeling is that changing CORBA in any but superficial ways will be
Yes. In fact I know one of the developers quite well.
I would be much happier w/ something built on an architecture similar to ICE. In a nutshell, when I need CORBA, I use TAO. But I really want something else. Jon
Jonathan Franklin skrev:
I would be much happier w/ something built on an architecture similar to ICE.
ICE seems nice. I have never really used it, just played around a bit some years ago. The problem as I see it, with ICE and other frameworks like it, is the fact that there are others like them that they usually are not compatible in critical ways. If everybody try to make their own standards we will not have any. That is the point of looking to IIOP or Web services, ICE, Spread, .Net remoting(on wire), ... etc. to provide solutions to compatibility with who you talk to on the wire. Essentially supporting existing and future wire standards, or standards in other layers in the protocol stack, with a single transparent C++ solution may be way more desirable than tossing in your own wanna-be communication standard. This is, and really should be much more a C++ community, and possibly standard, issue than it ever will become an issue for the members of OMG or other middleware providers. They are concerned with what languages to support, some of them want to support many languages with their single middleware product. Comercial tie-up is often more of a goal than a comfortable and smooth ride for their customers. Fredom of choice is something they only want until they got you. This would maybe be somewhat OK if any middle ware solution could talk to any other middleware solution. But that is typically not the case, typically you have to have the same product in both ends. The effect is income to middleware vendors and completly needless training, consultancy, porting and license cost for their customers. CORBA is here somewhat better than the pack of other solutions, comersial tie-up is harder for the vendors. If you really start to dislike great but expencive products like ORBExpress, then you can switch to any of the many other cheaper or free to use C++ ORBs. If it is transperent to the application code I write in C++ what transport or wire standard is used, then I will be very happy. In the C++ world this could be a traditional code generator like IDL to C++ or something like a compile time policy selection. But there could also be support for a deployment/runtime pluggable protocol support and maybe even a solution that transperently switch back-end between method invokations at run time. With something like that we are really closing in on something that would be of great use. One of the issues with the OO paradigm in middleware like CORBA is that it tends to lead users to somewhat bloat use of concepts, like objects with methods, when something simpler is all that is needed. In C++ I wich these requirements could be concepts like iterator concepts in STL. If all I need is message passing to an transport level end-point, then I use that concept requirenment in C++ code. If I really need a object to talk to on the other side, then I use a different concept. Then my function calls could be mapped to back end much like itterators to containers. Mapping between interface definition languages will also be needed to make all this work. But that is really orthognal to a new C++ mapping for CORBA et. al. There seems to be a CORBA IDL to WSDL mapping defined by OMG, and there are probably many others as well. I have not studied any of them. Side note: I think there are efforts by MS within the .Net framework to make transport transperent to .Net based clients. Likewise do many of the propriatory SOA frameworks do similar things. I whish we got this in standarized portable C++.
In a nutshell, when I need CORBA, I use TAO. But I really want something else.
Yes, but that does not exclude using CORBA ORBs like TAO as a back end for experimenting with a good C++ CORBA mapping. If feasable this mapping should become front end for middleware communication solutions in general. I therefore second the opinion that work on a C++ CORBA mapping is a great place to start. I also wish this work has more focus on the needs of the C++ comunity than the OMG generally ever will. That should definently not exclude OMG solutions/standards to new mappings, we should just have critical eyes to some details. Tie-up with CORBA in this C++ front end is one step on the way of being as bad as tie-up with propriatory or none standardized back ends. But I think, or hope, this may be avoided. In the end of the day, a solution with CORBA tie-up is much better than nothing, and I think it would be a great project standing on its own feet. -- Bjørn
On Wed, Apr 2, 2008 at 1:50 AM, Bjørn Roald <bjorn@4roald.org> wrote:
The problem as I see it, with ICE and other frameworks like it, is the fact that there are others like them that they usually are not compatible in critical ways.
Like I said in a previous post, you can build the New Thing on top of IIOP. Also, if you're not using the same object model (as defined in IDL), then you're not compatible anyway, whether everyone uses CORBA or not. We struggled for many years to get developers in the defense test & evaluation community to start using the same OM. Turned out to be terribly difficult, and only had marginal success. No one wanted to play nicely together. Hopefully they've made more progress since I left.
If everybody try to make their own standards we will not have any.
If everyone spends all their time trying to "fix" CORBA, we'll *never* get anything better. One simply needs look at the last 15 years of CORBA history to see this. I consider CORBA to be a Pinto, and just can't get excited about spending a bunch of effort in restoring it (to borrow an automotive analogy). ;-) But there is clearly interest from others out there, so it's probably not as hopeless as I think. Jon
Stefan Seefeld skrev:
vicente.botet wrote:
I think that a C++ CORBA implementation is a big deal. In addition a corba implemenation is not very useful without a minimal set of CORBA services.
I can imagine an experimental new C++ binding to be a worthy summer project. I have been using omniORB (http://omniorb.sourceforge.net/) heavily in the past, and I believe it to be easy enough to apply changes, in particular to its IDL compiler backend (which is written in Python), to generate code for such an alternative language binding.
In addition, some of the obvious changes are small and could be applied incrementally.
So, technically I don't see any reason not to try it, if someone's up to that task.
I agree that this aproach may be feasable to experiment with a new CORBA C++ language binding front end. Other CORBA implementations may also be used as back end in such an approach. TAO comes to my mind. I would probe interrest to support such a project from the developers of the candidate ORBs to see if they are willing to help. Note also that there has been work done on proposals for new CORBA language bindings for C++. I do not know the status or if anything has been made public or standardized in any way. The latest CORBA C++ language mapping at OMG.org is dated January 2008 but still contain the old binding stuff. No use of std::string or std::vector<T>, etc. that would make life so much simpler. I could not find a link, but I know I have seen postings on this in the past. Probably on the CORBA newsgroup. That is a good place to ask anyway. <wishfull_thinking> I would not mind at all if the C++ code I write for CORBA client or servers, i.e. the C++ in C++ to IDL mapping, was identical whether I used CORBA/IIOP or anything else of a number of other supported communication back-ends. I do not see the logic in why client or server source code should be concerned with details in the implementation of how data is transfered between them. Maybe differences need to be mapped to concepts much like std::iterator concepts so applications are hard-wired to requirements to the communication, not to the implementation as is more common today. </wishfull_thinking> -- bjørn
vicente.botet wrote:
I think that a C++ CORBA implementation is a big deal. In addition a corba implemenation is not very useful without a minimal set of CORBA services.
Yes, it's a big deal. I've been working on this for a *very* long time on my own.
Are you mapping idl files to C++ using a generator?
Yes, I have an IDL compiler.
Do you use the standard C++ mapping, or a mapping using more generic C++ techniques?
It's the standard mapping for now, but the underlying engine could be used underneath a new experimental mapping.
Could you present your current implementation, OS, middleware, ...
Runs on UNIX (Solaris), Linux and Windows NT or later.
Could you present a little bit your project, contents, architecture, ...
Here's the basics of what I've got: 1. An IDL compiler, currently mostly written in Perl, but I've been thinking about rewriting it using Wave and Spirit. 2. An ORB library to link with. This includes a pretty much complete implementation of CORBA 2.6, including the C++ binding, GIOP/IIOP implementation, valuetypes and abstract interfaces, the Dynamic Invocation and Skeleton interfaces, and almost all of the CORBA messaging specification (async and polling invocations and the policy framework). I have a partial implementation of portable interceptors. 3. Naming service and a simplistic implementation launching service.
Do you have everything you need already in Boost?
With ASIO and the newer Thread library, I think I have everything I need for the ORB library. I have been using ACE up till now. (I actually started this project long before the ACE team started TAO.) If I rewrite the IDL compiler in Wave and Spirit, then I won't need Perl anymore either. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org
From: "Jonathan Biggar" <jon@biggar.org> Subject: Re: [boost] CORBA iimplementation for Boost interest?
vicente.botet wrote:
I think that a C++ CORBA implementation is a big deal. In addition a corba implemenation is not very useful without a minimal set of CORBA services.
Yes, it's a big deal. I've been working on this for a *very* long time on my own.
Are you mapping idl files to C++ using a generator?
Yes, I have an IDL compiler.
This is a good starting point.
Do you use the standard C++ mapping, or a mapping using more generic C++ techniques?
It's the standard mapping for now, but the underlying engine could be used underneath a new experimental mapping.
I think that we need an standard binding, otherwise application that use already the standard binding (throug other CORBA implementations) could not switch to the Boost one without major changes. I'm sure that you should have already a lot of work boostifying your current implementation. A more C++-friendly interface binding will need more experimental work, and I'm sure that there will be a lot of boosters that have already a lot of ideas. Maybe some one really involved in this task can start a new page on the Boost wiki. This more C++-friendly binding could be : * a wrapper to the standard C++ binding or C binding * a new inteface idependent from the standard C++ binding and using a common infrastructure - a wrapper has the advantage to be used with other ORB providers and the drawback to be constrained by the standard binding, - a new interface idependent from the current binding has the advantage of freedom but could not be reused with other ORB providers. The definition of this common infrastructure will be already un interesting project by itself.
Could you present your current implementation, OS, middleware, ...
Runs on UNIX (Solaris), Linux and Windows NT or later.
Could you present a little bit your project, contents, architecture, ...
Here's the basics of what I've got:
1. An IDL compiler, currently mostly written in Perl, but I've been thinking about rewriting it using Wave and Spirit.
Even if this is an interesting project by itself, I think that it has a lower priority than boostifying your current implementation.
2. An ORB library to link with. This includes a pretty much complete implementation of CORBA 2.6, including the C++ binding, GIOP/IIOP implementation, valuetypes and abstract interfaces, the Dynamic Invocation and Skeleton interfaces, and almost all of the CORBA messaging specification (async and polling invocations and the policy framework). I have a partial implementation of portable interceptors.
Could you enumerate the features your implementation do not provides? Which one will be mandatory for a first release?
3. Naming service and a simplistic implementation launching service.
Do you have everything you need already in Boost?
With ASIO and the newer Thread library, I think I have everything I need for the ORB library. I have been using ACE up till now. (I actually started this project long before the ACE team started TAO.) If I rewrite the IDL compiler in Wave and Spirit, then I won't need Perl anymore either.
I'm surprised that using ACE currently you don't need nothing more not yet pressent in Boost. I suppose then that your implementation will contain a lot of infrastructure classes that could be seen as separated libraries. We will see.
-- Jon Biggar
Finnaly, I see atleast three independent projects: * the one you were proposing initially, boostify your ORB implementation * boostify the IDL to C++ compiler * look for a more c++-friendly interface Thanks for your answer. Have a good project _____________________ Vicente Juan Botet Escriba
vicente.botet wrote:
2. An ORB library to link with. This includes a pretty much complete implementation of CORBA 2.6, including the C++ binding, GIOP/IIOP implementation, valuetypes and abstract interfaces, the Dynamic Invocation and Skeleton interfaces, and almost all of the CORBA messaging specification (async and polling invocations and the policy framework). I have a partial implementation of portable interceptors.
Could you enumerate the features your implementation do not provides? Which one will be mandatory for a first release?
It's pretty complete per CORBA 2.5. Most of what is missing is a few things around the edges. Here's a pretty comprehensive list: 1. No support for Valuetype SendingContextCodeBase, but I think that's primarily a Java thing anyway. 2. No support for the Realtime ORB specification. I wasn't targeting realtime programming, but some of this is useful for non-realtime work too. 3. No implementation of Persistent Requests per the CORBA Messaging specification. I don't know of an ORB that implements this. 4. Some missing stuff around the DynAny interface for valuetypes and valueboxes, since the spec is somewhat unclear and perhaps unimplementable here. 5. There's only a partial client side implemetation of the Portable Interceptors specification. This is where I was last concentrating my work. 6. Several dozen small issues to bring it up to CORBA 2.6. 7. No support for CORBA 3.0 features: local objects, component specification, Object Reference Template stuff. 8. The usual laundry list of known issues & bugs. :)
3. Naming service and a simplistic implementation launching service.
Do you have everything you need already in Boost? With ASIO and the newer Thread library, I think I have everything I need for the ORB library. I have been using ACE up till now. (I actually started this project long before the ACE team started TAO.) If I rewrite the IDL compiler in Wave and Spirit, then I won't need Perl anymore either.
I'm surprised that using ACE currently you don't need nothing more not yet pressent in Boost.
I didn't use much if any of the high level ACE classes. Just the threading, sockets, reactor and/or proactor stuff.
I suppose then that your implementation will contain a lot of infrastructure classes that could be seen as separated libraries. We will see.
Perhaps. Things like the CDR encoding classes could easily be broken out into a separate library. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org
Hello Jon, Jonathan Biggar wrote:
I've been working on a C++ CORBA implementation for a long time. I've considered making it open source in the past, but I hadn't seen the exact niche for it to fill.
Now that Boost 1.35 is out, including ASIO and the new Threads implementation, I'm considering retargeting my implementation to only use boost libraries for underlying services.
I'd be quite happy to contribute my implementation to boost, if there's enough interest for me to proceed.
So, what do you all think?
That's wonderful! (I am so happy also because I know, being a long-time CORBA user, the expertise of Jonathan and his contributions to the standard). Some considerations: - I think that many on this list underestimate the importance that CORBA has still today. For large client-server/distributed applications there aren't yet many valid alternatives. - The main benefit of CORBA is its cross-platform, cross-language nature: our C++ distributed application is accessible through C++, Java, Python, COM, .Net in Solaris, Windows, Mac OS X and Linux. - There are very good open-source implementations, like TAO and OmniORB, with great support facilities. - The main drawback of CORBA is probably its awkward C++ binding (as Jon said, there were many /historic/ reasons). I know that an effort for a new binding began some months ago at OMG: I am not updated on that one. TAO is a robust implementation based on ACE. ACE is a large C++ framework, which implements many network-related pattens. Boost is now entering the ACE's territory with a much more modern C++ perspective but it still lacks many features (waiting for pion-net/cpp-netib, log et al.). But, as Jon said, Boost has now the functionalities needed to build an ORB. I see many benefits about a Boost ORB: - A modern C++ implementation -
Jonathan Biggar wrote:
I've been working on a C++ CORBA implementation for a long time. I've considered making it open source in the past, but I hadn't seen the exact niche for it to fill.
Now that Boost 1.35 is out, including ASIO and the new Threads implementation, I'm considering retargeting my implementation to only use boost libraries for underlying services.
I'd be quite happy to contribute my implementation to boost, if there's enough interest for me to proceed.
So there appears to be some interest, and even more interest if it leads to developing a new more modern C++ binding for CORBA. But having an implementation of the current binding would be a huge start for that. So on this basis, I plan to proceed. Here's my plan to boostify the ORB: 1. Remove the dependency on ACE thread, sockets and event dispatch classes and replacing them with the equivalents from boost. 2. Boostify the source code per the documented boost guidelines. This includes: a. Reorganizing the source directories b. changing header & source files to use boost standards for license, include paths, macros, etc c. making the project compile with bjam d. convert the tests to use the Boost test framework 3. Convert/Write documentation in Boost "standard" format. Since this is an implementation of an OMG standard, the documentation will focus on details of the implementation that are outside the scope of the standard or are implementation defined. Once I've done this, I'll release the source for informal examination and feeback from the Boost community, with the eventual plan to make a formal submission review request. Once (speaking optimistically) the library is accepted as part of Boost, we can work on a new C++ binding. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org
Jonathan Biggar wrote:
So there appears to be some interest, and even more interest if it leads to developing a new more modern C++ binding for CORBA. But having an implementation of the current binding would be a huge start for that.
I don't quite agree. In particular, I think the phrasing above is quite a bit misleading: I wouldn't characterize an ORB as an 'implementation of a C++ binding'. And I also don't agree that a new ORB implementation is required as a prerequisite for a new C++ binding. The reason I'm pointing this out is that I don't see any value in yet another ORB. Lots of time has been spent on existing ones to get decent performance, etc., and I think it's just naive and foolish to start all over, just to be able to pretend that this one is built with boost. Yet another case of Not-Invented-Here ? Pick a good, free, ORB (the two choices that immediately come to mind are omniORB and TAO), and try to make modifications so it can be used with an alternate C++ binding. I think this would be a much more reasonable plan to move forward. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Thu, Apr 3, 2008 at 4:37 PM, Stefan Seefeld <seefeld@sympatico.ca> wrote:
Jonathan Biggar wrote:
So there appears to be some interest, and even more interest if it leads to developing a new more modern C++ binding for CORBA. But having an implementation of the current binding would be a huge start for that.
<snip>
Pick a good, free, ORB (the two choices that immediately come to mind are omniORB and TAO), and try to make modifications so it can be used with an alternate C++ binding. I think this would be a much more reasonable plan to move forward.
So, I'll preface by saying that I'll try to stop being a Curmudgeon about CORBA. I do agree w/ Stefans about yet another ORB. One thing that may be really useful would be to build an IDL grammar in Spirit, and make it available for other CORBA hacks to experiment w/ alternative bindings. Jon
Stefan Seefeld wrote:
Jonathan Biggar wrote:
So there appears to be some interest, and even more interest if it leads to developing a new more modern C++ binding for CORBA. But having an implementation of the current binding would be a huge start for that.
I don't quite agree. In particular, I think the phrasing above is quite a bit misleading: I wouldn't characterize an ORB as an 'implementation of a C++ binding'. And I also don't agree that a new ORB implementation is required as a prerequisite for a new C++ binding.
The reason I'm pointing this out is that I don't see any value in yet another ORB. Lots of time has been spent on existing ones to get decent performance, etc., and I think it's just naive and foolish to start all over, just to be able to pretend that this one is built with boost. Yet another case of Not-Invented-Here ?
Pick a good, free, ORB (the two choices that immediately come to mind are omniORB and TAO), and try to make modifications so it can be used with an alternate C++ binding. I think this would be a much more reasonable plan to move forward.
Stefan, I'm not going to implement a new ORB, I already have one that has been under development for over 10 years, and it provides several CORBA features that are not implemented in omniORB or TAO, such as the polling asynchronous invocation model, a complete implementation of valuetypes, and more of the Messaging QoS policies. And from my experience, much of an ORB implementation is pretty intricately tied into the C++ binding. Redevelopment of a new binding will touch a very large part of the ORB source code anyway. Having an ORB that uses the Boost Thread and ASIO libraries also means applications that use those boost libraries can easily use an ORB too without integration problems. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org
On Thu, Apr 3, 2008 at 5:33 PM, Jonathan Biggar <jon@biggar.org> wrote:
And from my experience, much of an ORB implementation is pretty intricately tied into the C++ binding. Redevelopment of a new binding will touch a very large part of the ORB source code anyway.
Yes, this is very true. Regarding what I suggested w/ Spirit, we would probably want to provide the parser w/ more than a dummy generator. It would of course have to spit out ORB-specific code. Would be very cool if you could specify different generators for different ORBs, or something like that.
Having an ORB that uses the Boost Thread and ASIO libraries also means applications that use those boost libraries can easily use an ORB too without integration problems.
True to some extent. It's not that difficult to multiplex calls to orb::run() or just give the orb its own thread. If you have a nice modern C++ ORB implemented, then by all mean, make it available. Jon
Ok, I've been entirely too busy to really read this thread -- I skimmed a few posts. A few points...hopefully it won't be too redundant. I think this would be a great contribution to boost, please do proceed. Second, I know the OMG recently started discussing a new C++ binding. This thread might be useful for the interested: http://groups.google.com/group/comp.soft-sys.ace/browse_thread/thread/339014... Third, I'd like to see the Boost community contribute and make recommendations to a new CORBA binding. Or better yet, just build one. As *the* home of all things C++ there's no group more qualified to get the C++ part right. Last thought. Any of you'all coming to BoostCon? I'd be happy to set up a Birds of a feather session one evening to work on this. Kevin Heifner from OCI (they provide commercial support for TAO) will be presenting threading @ BoostCon -- I'm certain he'd be interested in this topic. Jeff
On Fri, Apr 4, 2008 at 12:19 AM, Jeff Garland <azswdude@gmail.com> wrote:
http://groups.google.com/group/comp.soft-sys.ace/browse_thread/thread/339014...
Interesting thread.
<http://groups.google.com/group/comp.soft-sys.ace/browse_thread/thread/339014494e602622>Third, I'd like to see the Boost community contribute and make recommendations to a new CORBA binding. Or better yet, just build one.
Just building one is probably the best way to get something done... Then let OMG squabble over it ad nausium while the community uses and perfects it. :-) Last thought. Any of you'all coming to BoostCon? I'd be happy to set up a
Birds of a feather session one evening to work on this.
I'll be there, and would be interested in talking about this (and other middleware topics) with others. Thanks Jeff, Jon
Jeff Garland wrote:
I think this would be a great contribution to boost, please do proceed. Second, I know the OMG recently started discussing a new C++ binding. This thread might be useful for the interested:
http://groups.google.com/group/comp.soft-sys.ace/browse_thread/thread/339014...
Also take a look at http://www.dre.vanderbilt.edu/~schmidt/C++-mapping.ppt
Third, I'd like to see the Boost community contribute and make recommendations to a new CORBA binding. Or better yet, just build one. As *the* home of all things C++ there's no group more qualified to get the C++ part right.
There are some interest in the ACE/TAO community to support work on C++ bindings in the boost community. So there is one ORB and likely vendors behind it that are willing to contribute.
Last thought. Any of you'all coming to BoostCon?
Sorry, would love to come but not this time.
Kevin Heifner from OCI (they provide commercial support for TAO) will be presenting threading @ BoostCon -- I'm certain he'd be interested in this topic.
I would also bet on that ;-) -- Bjørn
Jeff Garland wrote:
Last thought. Any of you'all coming to BoostCon? I'd be happy to set up a Birds of a feather session one evening to work on this. Kevin Heifner from OCI (they provide commercial support for TAO) will be presenting threading @ BoostCon -- I'm certain he'd be interested in this topic.
Yes, very interested. We have had many conversations about a new mapping around OCI. KevinH -- Kevin Heifner heifner @ ociweb.com http://heifner.blogspot.com Object Computing, Inc. (OCI) www.ociweb.com
Jeff Garland wrote:
Last thought. Any of you'all coming to BoostCon? I'd be happy to set up a Birds of a feather session one evening to work on this. Kevin Heifner from OCI (they provide commercial support for TAO) will be presenting threading @ BoostCon -- I'm certain he'd be interested in this topic.
I think it would be fun to come to BoostCon, because I find myself with plenty of time but not enough funds to do so. The company I worked for closed its doors without warning on Monday, so a couple of grand to come to BoostCon is out of the question, unless someone wants to offer a scholarship. :) I decided to offer my ORB to boost now partly because I needed something to keep me busy while I'm job hunting. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org
Hello, I think that there are atleast 3 CORBA related projects: Orb- Boostification of the Jonathan ORM implementation that was the origin of this thread (Maybe someone else want to boostify TAO+ACE) Idl2Cpp- Idl to C++ compiler NewCppBinding- New C++ binding on top of an existing ORB implementation (without Idl2Cpp compiler). These three projects can start in parallel and they are independent. One the NewCppBind start to make sens we will need to modify the Idl2Cpp for the new binding. The Orb implementation is interesting for atleast 4 rasions: * If the new c++ binding could be not possible without modification of the ORB back end. * The mapping could be facilitated when we can do some modification to the ORB back end. * Performances could imply that without been able to mody the ORB the new binding is not usable. * In addition, I think that the implementation of an ORB needs a lot of infrastructure that could finish as separated Boost libraries available to the boost community. For the momment I see that Jonathan wants to start with the Boostification of its ORB implementation and then Idl2Cpp using Boost libraries. Someone wants to take the responsability to start the NewCppBinding project? Some comments follows. Regards _____________________ Vicente Juan Botet Escriba From: "Stefan Seefeld" <seefeld@sympatico.ca> Subject: Re: [boost] CORBA iimplementation for Boost interest?
Jonathan Biggar wrote:
So there appears to be some interest, and even more interest if it leads to developing a new more modern C++ binding for CORBA. But having an implementation of the current binding would be a huge start for that.
I don't quite agree. In particular, I think the phrasing above is quite a bit misleading: I wouldn't characterize an ORB as an 'implementation of a C++ binding'. And I also don't agree that a new ORB implementation is required as a prerequisite for a new C++ binding.
You are maybe right. You can always implement a new C++ binding on top of the standard one. This is IMO a separated project that allow to experiment already with existings ORB implementations. One of the thinks that this new binding should support is IMO that both bindings can live together on the same application, allowing a smooth transition.
The reason I'm pointing this out is that I don't see any value in yet another ORB. Lots of time has been spent on existing ones to get decent performance, etc., and I think it's just naive and foolish to start all over, just to be able to pretend that this one is built with boost. Yet another case of Not-Invented-Here ?
I'm sure that when doing this task we will confront with some problems that could have a better solution if we don't need to map to the standard binding. And there it will be really interesting to be able to modify an ORB implementation. As there is enough work for all and more, please can we construct together each one on its prefered project.
Pick a good, free, ORB (the two choices that immediately come to mind are omniORB and TAO), and try to make modifications so it can be used with an alternate C++ binding. I think this would be a much more reasonable plan to move forward.
What do you will do with the omniORB or TAO modifications? Will you integrate them its current releases?
vicente.botet wrote:
Hello,
I think that there are atleast 3 CORBA related projects: Orb- Boostification of the Jonathan ORM implementation that was the origin of this thread (Maybe someone else want to boostify TAO+ACE) Idl2Cpp- Idl to C++ compiler NewCppBinding- New C++ binding on top of an existing ORB implementation (without Idl2Cpp compiler).
These three projects can start in parallel and they are independent.
Not quite. An IDL to C++ compiler has no meaning outside the realm of a particular ORB, as it needs to generate code (not only the user-visible 'C++ binding') that ties into the ORB internals. I agree that writing / porting an ORB is mostly independent of working on the C++ binding...at least if the design is right. It is true that the effects of changes to the C++ binding may reach deep into the ORB internals, but ideally that would be well separated. It depends on the target ORB. Finally, as the topic came up, too: rewriting an IDL compiler requires a frontend (IDL parser) and a backend (ORB-specific code generator). I'll bring up the same argument here: I don't see much value in rewriting the IDL parser, just because we can. Take the omniidl tool that ships with omniORB: it is very well designed (internal AST representation generated by a bison/flex/C++-based parser and a Python-based code generator) and it's straight forward to simply provide a new backend generating code for a new and experimental C++ binding. (It already has two backends to generate C++ and Python bindings for the current omniORB.) So, I'd rather see a focus on a new C++ binding instead of constantly getting side-tracked into tangential projects that I believe don't provide as much value to this community.
So there appears to be some interest, and even more interest if it leads to developing a new more modern C++ binding for CORBA. But having an implementation of the current binding would be a huge start for that.
I don't quite agree. In particular, I think the phrasing above is quite a bit misleading: I wouldn't characterize an ORB as an 'implementation of a C++ binding'. And I also don't agree that a new ORB implementation is required as a prerequisite for a new C++ binding.
You are maybe right. You can always implement a new C++ binding on top of the standard one.
That's not what I'm saying. A new binding is independent of the old one, and adding support for it to an existing ORB requires both, changes to the ORB itself (what that means depends on the design of the given ORB), as well as changes to the code-generating part (the 'backend') of the IDL-to-C++ compiler.
This is IMO a separated project that allow to experiment already with existings ORB implementations. One of the thinks that this new binding should support is IMO that both bindings can live together on the same application, allowing a smooth transition.
That would be good indeed, but again, is much more a concern of an ORB implementor (which I hope boost will not become, as large as it already is).
The reason I'm pointing this out is that I don't see any value in yet another ORB. Lots of time has been spent on existing ones to get decent performance, etc., and I think it's just naive and foolish to start all over, just to be able to pretend that this one is built with boost. Yet another case of Not-Invented-Here ?
I'm sure that when doing this task we will confront with some problems that could have a better solution if we don't need to map to the standard binding. And there it will be really interesting to be able to modify an ORB implementation.
Sure, implementing a new binding requires the ability to change the ORB. But does that imply that the ORB should be part of and be implemented in , boost ?
As there is enough work for all and more, please can we construct together each one on its prefered project.
I'm not telling anybody what to work on. I'm just concerned that, if boost reaches into even more domains, it will loose focus and be even harder to maintain. (Of course, if boost was more modular all this would be much less of a concern.)
Pick a good, free, ORB (the two choices that immediately come to mind are omniORB and TAO), and try to make modifications so it can be used with an alternate C++ binding. I think this would be a much more reasonable plan to move forward.
What do you will do with the omniORB or TAO modifications? Will you integrate them its current releases?
To me this whole project of experimenting with a new C++ binding is more of a sandbox project anyways, that would profit from the experience of the boost community with the C++ language. So, in the end, an actual implementation could very well be contributed to whatever ORB was used to do the experimentation with. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
Hello Stefan, Stefan Seefeld wrote: <snip/>
So, I'd rather see a focus on a new C++ binding instead of constantly getting side-tracked into tangential projects that I believe don't provide as much value to this community.
<snip/>
To me this whole project of experimenting with a new C++ binding is more of a sandbox project anyways, that would profit from the experience of the boost community with the C++ language. So, in the end, an actual implementation could very well be contributed to whatever ORB was used to do the experimentation with.
While I understand your concerns, I do not agree. My points are: - Jon is offering an already implemented ORB with an IDL parser: while the parser front-end will probably need a complete rewrite, the rest of the code needs only some refactoring due to the /boostification/. He is not going to implement the whole _huge_ thing from scratch. - I think, like Jeff Garland, that Boost is the right place to discuss about a new C++ mapping: not only because many C++ experts follow this forum, but also because this is a very _active_ place, while the same cannot be said for the majority of CORBA groups, excluding perhaps comp.soft-sys.ace. Having a Boost ORB could be the best way to have the right focus here. - An ORB using the Boost libraries underneath has the advantage, like Jon said, to ease the integration within applications using the same libraries. - I don't think one should always see these initiatives as the effect of a NIH syndrome. Competition is good also for open source projects. Besides, the effort for a new C++ binding could start here but it could receive the support and the advices of e.g. the ACE/TAO and OmniORB communities. Best regards, Stefano
Stefano Delli Ponti wrote:
My points are:
- Jon is offering an already implemented ORB with an IDL parser: while the parser front-end will probably need a complete rewrite, the rest of the code needs only some refactoring due to the /boostification/. He is not going to implement the whole _huge_ thing from scratch.
Yes, understood. However, there is much more effort going into a project than development. What about maintenance (adapting to new compilers, say), compiling all the new code and running all the new regression tests that such a project would surely add ? This impacts the whole boost project. (Again, with a modular boost where components would be built / tested / released all this would be mood.) Also, as boost right now is released as a single entity, another concern is the perception from users. Boost already is huge. The boost developers not actively supporting modularization or even simple (platform-neutral) packaging really doesn't help. Again, would boost not be a single entity, all these arguments would be void. Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Fri, Apr 4, 2008 at 8:03 AM, Stefan Seefeld <seefeld@sympatico.ca> wrote:
Stefano Delli Ponti wrote:
Yes, understood. However, there is much more effort going into a project than development. What about maintenance (adapting to new compilers, say), compiling all the new code and running all the new regression tests that such a project would surely add ? This impacts the whole boost project. (Again, with a modular boost where components would be built / tested / released all this would be mood.)
I don't see why this project is any different than any other boost library project. It adds one more library to an aleady large collection. I suspect the only way to solve this problem would be to move toward a 'pull as you need it' solution (more like cpan) where there's a core boost install and then an easy way to get the other libriaries one at a time or in batches. But we still have to test them, etc. And it's still important for us to have major releases because there's some folks that simply won't look at libraries that aren't part of a major release.
Also, as boost right now is released as a single entity, another concern is the perception from users. Boost already is huge. The boost developers not actively supporting modularization or even simple (platform-neutral) packaging really doesn't help.
I'm not sure how we "aren't supporting" modularization. Boost actually is quite modular -- you can use bcp to snip out subparts for your needs -- or do it by hand. I've certainly done it -- "rm -rf" is a handy tool for the parts I don't need.
Again, would boost not be a single entity, all these arguments would be void.
I'm all for alternative releases, modularization, etc but I think we still need a simple way to get the whole enchilada at once. Jeff
Jeff Garland wrote:
On Fri, Apr 4, 2008 at 8:03 AM, Stefan Seefeld <seefeld@sympatico.ca> wrote:
Stefano Delli Ponti wrote:
Yes, understood. However, there is much more effort going into a project than development. What about maintenance (adapting to new compilers, say), compiling all the new code and running all the new regression tests that such a project would surely add ? This impacts the whole boost project. (Again, with a modular boost where components would be built / tested / released all this would be mood.)
I don't see why this project is any different than any other boost library project.
Right, it isn't.
It adds one more library to an aleady large collection. I suspect the only way to solve this problem would be to move toward a 'pull as you need it' solution (more like cpan) where there's a core boost install and then an easy way to get the other libriaries one at a time or in batches.
Yes.
But we still have to test them, etc. And it's still important for us to have major releases because there's some folks that simply won't look at libraries that aren't part of a major release.
So what ? If I wouldn't look at a library just because it isn't part of the 'core' release, it might just be because I have no need for it. What's the deal ?
Also, as boost right now is released as a single entity, another concern is the perception from users. Boost already is huge. The boost developers not actively supporting modularization or even simple (platform-neutral) packaging really doesn't help.
I'm not sure how we "aren't supporting" modularization. Boost actually is quite modular -- you can use bcp to snip out subparts for your needs -- or do it by hand. I've certainly done it -- "rm -rf" is a handy tool for the parts I don't need.
Yeah, I have heard that argument a lot, and I have to admit that I think it's a phony one. Sure, "I can use bcp", if I'm willing to compile and package boost myself. What if I'm an end user of another program that happens to depend on some boost component ? In that case, I need to pull in boost as a prerequisite for the software I'm interested in, and I don't care how boost got built in the first place. All I see is a huge package. And, again, there is this development / maintenance overhead. The other night I was considering offering to become a tester for x86-64 / Linux / GCC 4.3. But as there (apparently) is no way to offer compiling / testing for individual components, you just push the barrier of entry higher with each addition to boost, as the testing cycle becomes ever more resource intensive. Why is this so hard to understand ?
Again, would boost not be a single entity, all these arguments would be void.
I'm all for alternative releases, modularization, etc but I think we still need a simple way to get the whole enchilada at once.
I don't understand the issue. Once you have modularized your enchilada, you are free to release the whole thing in a batch, if you so choose, but users can still pick whatever component they really need (plus their prerequisites, obviously). Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...
On Fri, Apr 4, 2008 at 9:15 AM, Jeff Garland <azswdude@gmail.com> wrote:
I don't see why this project is any different than any other boost library project. It adds one more library to an aleady large collection.
Well, CORBA is more than just a "generally useful" library. Using it effectively usually requires external runtime services (e.g. NamingService), but you know that. It's not exactly an apples to apples comparison. Sorry, if I'm tossing more gas on the fire. Jon
Jonathan Franklin wrote:
On Fri, Apr 4, 2008 at 9:15 AM, Jeff Garland <azswdude@gmail.com> wrote:
I don't see why this project is any different than any other boost library project. It adds one more library to an aleady large collection.
Well, CORBA is more than just a "generally useful" library. Using it effectively usually requires external runtime services (e.g. NamingService), but you know that. It's not exactly an apples to apples comparison.
Yes, it has a few more requirements than the usual boost library, since you must have standalone executables--IDL compiler and NameService as a minimum. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org
Jonathan Franklin wrote:
On Fri, Apr 4, 2008 at 9:15 AM, Jeff Garland <azswdude@gmail.com> wrote:
I don't see why this project is any different than any other boost library project. It adds one more library to an aleady large collection.
Well, CORBA is more than just a "generally useful" library. Using it effectively usually requires external runtime services (e.g. NamingService), but you know that.
I do, but that doesn't mean I was thinking about it when I was reading this thread ;-)
It's not exactly an apples to apples comparison.
Sorry, if I'm tossing more gas on the fire.
Not at all -- I might have been missing the point that when you start adding other services (ie: if you tried to rebuild all of the TAO stuff) it's a massive thing. And that's a good point -- I was coming from the perspective of just the core orb is really all that would be part of the initial effort. Anyway, fwiw I think the order of focus priority should be as follows: 1) new binding interface / idl compiler 2) boostified orb Because I do agree in the end that having another orb is less valuable than having a modern binding someone would enjoy using. I think that to really do the new interface you'd have to work the idl compiler piece to do any experiments of scale. But maybe some examples can be done by hand to get started and lay down the principles. Of course, the decision of focus is up to Jon, but there's not many people that know both Corba and C++ well enough to really start laying out a new binding... Jeff
Here's a status report on my progress so far. Jonathan Biggar wrote:
So there appears to be some interest, and even more interest if it leads to developing a new more modern C++ binding for CORBA. But having an implementation of the current binding would be a huge start for that.
So on this basis, I plan to proceed. Here's my plan to boostify the ORB:
1. Remove the dependency on ACE thread, sockets and event dispatch classes and replacing them with the equivalents from boost.
I now have a running ORB that only uses BOOST libraries. There's probably some code that needs restructuring, since I used the ACE Reactor pattern and have made pretty much the minimal changes to use Boost.asio's Proactor pattern instead. So the code isn't quite as neat as I'd like. But that refactoring can wait until later.
2. Boostify the source code per the documented boost guidelines. This includes:
a. Reorganizing the source directories b. changing header & source files to use boost standards for license, include paths, macros, etc
I've done most of this, but I have a few more TODOs on my list.
c. making the project compile with bjam
This is my next major task. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org
Hi Jonathan, All these are good news. Continue and let us knwo any major achievement on your development. Cheers Vicente ----- Original Message ----- From: "Jonathan Biggar" <jon@biggar.org> To: <boost@lists.boost.org> Sent: Wednesday, May 21, 2008 8:37 PM Subject: Re: [boost] CORBA iimplementation for Boost interest?
Here's a status report on my progress so far.
Jonathan Biggar wrote:
So there appears to be some interest, and even more interest if it leads to developing a new more modern C++ binding for CORBA. But having an implementation of the current binding would be a huge start for that.
So on this basis, I plan to proceed. Here's my plan to boostify the ORB:
1. Remove the dependency on ACE thread, sockets and event dispatch classes and replacing them with the equivalents from boost.
I now have a running ORB that only uses BOOST libraries. There's probably some code that needs restructuring, since I used the ACE Reactor pattern and have made pretty much the minimal changes to use Boost.asio's Proactor pattern instead. So the code isn't quite as neat as I'd like. But that refactoring can wait until later.
2. Boostify the source code per the documented boost guidelines. This includes:
a. Reorganizing the source directories b. changing header & source files to use boost standards for license, include paths, macros, etc
I've done most of this, but I have a few more TODOs on my list.
c. making the project compile with bjam
This is my next major task.
-- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org
_______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost
David Rodríguez Ibeas wrote:
On Wed, May 21, 2008 at 8:37 PM, Jonathan Biggar <jon@floorboard.com> wrote:
Here's a status report on my progress so far.
Is the new version available? Great work.
I'll make it available once I have it building with boost build. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org
Jonathan Biggar wrote:
David Rodríguez Ibeas wrote:
On Wed, May 21, 2008 at 8:37 PM, Jonathan Biggar <jon@floorboard.com> wrote:
Here's a status report on my progress so far.
Is the new version available? Great work.
I'll make it available once I have it building with boost build.
Great! Have you done any testing of IIOP compliance and C++ mapping compliance. Maybe I can help with some of that testing if it is needed. What revisions of the CORBA standards are the target for your ORB? Do you implement IR and DII ? I ask because I have special interest in those. We have worked around missing IR and DII in other ORBs, but it would be nice if it was directly supported. Do you plan any support for the QoS provisions and RT CORBA? -- Bjørn
Bjørn Roald wrote:
I'll make it available once I have it building with boost build.
Great! Have you done any testing of IIOP compliance and C++ mapping compliance. Maybe I can help with some of that testing if it is needed.
I've done some interoperability testing with TAO and JacORB, so I don't expect too many problems.
What revisions of the CORBA standards are the target for your ORB?
It's pretty close to clean CORBA 2.5. I've got a handful of things to doublecheck or fix for CORBA 2.6 compliance.
Do you implement IR and DII ?
I implement the full DII and DSI, but I haven't written an IR yet. My plan for an IR is to implement another IDL compiler backend that outputs data files that can be bulk imported into the IR.
I ask because I have special interest in those. We have worked around missing IR and DII in other ORBs, but it would be nice if it was directly supported.
Do you plan any support for the QoS provisions and RT CORBA?
I support the Messaging QoS policies, but nothing from RT yet. I don't intent to promote this as an RT ORB, but there are still features of the RT spec that are useful for a "normal" ORB (thread pools, priorities, etc). -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org
Jonathan Biggar wrote:
Bjørn Roald wrote:
I'll make it available once I have it building with boost build.
Great! Have you done any testing of IIOP compliance and C++ mapping compliance. Maybe I can help with some of that testing if it is needed.
I've done some interoperability testing with TAO and JacORB, so I don't expect too many problems.
Sounds good for now. I am looking forward to have a look.
What revisions of the CORBA standards are the target for your ORB?
It's pretty close to clean CORBA 2.5. I've got a handful of things to doublecheck or fix for CORBA 2.6 compliance.
Great, I don't really know, but I think the CORBA 3 specs are mostly about the CCM additions. So I guess that 2.6 is mostly the same as 3.0 for what I think you will you provide.
Do you implement IR and DII ?
I implement the full DII and DSI, but I haven't written an IR yet. My plan for an IR is to implement another IDL compiler backend that outputs data files that can be bulk imported into the IR.
An IR that can load quickly is always nice.
I ask because I have special interest in
those. We have worked around missing IR and DII in other ORBs, but it would be nice if it was directly supported.
Do you plan any support for the QoS provisions and RT CORBA?
I support the Messaging QoS policies, but nothing from RT yet. I don't intent to promote this as an RT ORB, but there are still features of the RT spec that are useful for a "normal" ORB (thread pools, priorities, etc)
Ok. I guess some of this can and will come along with time if it is accepted in boost. -- Bjørn
Status report... Jonathan Biggar wrote:
So on this basis, I plan to proceed. Here's my plan to boostify the ORB:
1. Remove the dependency on ACE thread, sockets and event dispatch classes and replacing them with the equivalents from boost.
2. Boostify the source code per the documented boost guidelines. This includes:
a. Reorganizing the source directories b. changing header & source files to use boost standards for license, include paths, macros, etc c. making the project compile with bjam
I now can take a tarball of my ORB source, untar it into a boost 1.35.0 distribution tree and type 'bjam --v2' and see my ORB library get built. In the meantime, I've also completed upgrading the ORB to CORBA 2.6, except for a few small known issues. I've also implemented a few CORBA 3.0 items, primarily the changes that changed many ORB objects to be local interfaces. I've got to take one more pass over everything and add boost compatible copyright headers, and then I'll make an alpha version available for people to play with. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org
Stefano Delli Ponti wrote:
Jonathan Biggar wrote:
Status report... ... I've got to take one more pass over everything and add boost compatible copyright headers, and then I'll make an alpha version available for people to play with.
This is very good news! What about the IDL compiler?
The IDL compiler is still in perl at this point. I did take the time to convert the C++/bison based grammar parser to pure perl using yapp, since BBv2 was giving me fits trying to set it up to build a loadable perl extension. Converting the IDL compiler to wave/spirit is a significant project. I plan to start on that after I get an alpha package out. I do have some cool ideas on how to architect it so that the boilerplate generated code segments are kept in library files that are read in at runtime to avoid having to rebuild the IDL compiler after every little code tweak. -- Jon Biggar Floorboard Software jon@floorboard.com jon@biggar.org
participants (11)
-
Bjørn Roald -
David Rodríguez Ibeas -
Jeff Garland -
Jeff Garland -
Jonathan Biggar -
Jonathan Franklin -
Kevin Heifner -
Sohail Somani -
Stefan Seefeld -
Stefano Delli Ponti -
vicente.botet