...various comments about ACE from various authors.... > >> [...] > >> How about borrowing ideas from ACE, but implementing them in > >> modern C++? Or has that been discussed already? Or is the ACE > >> framework too obsolete-C++ to be a useful design? > > > > We probably should at least consider ACE ideas. But I guess this would > > require several of us to dig into ACE which would delay further a Boost > > socket library. However ACE could be a valuable investment?
I have some pretty deep experience with using ACE. ACE has many excellent design constructs. It uses a mix of Object Oriented and template approaches. In fact, it was using policy-based design before it became 'popular'. One example of good design is the use of a portability layer (ACE_OS) to wrap up the variations in the C API's. This greatly simplifies porting. I think that we are (and should continue) to be evaluating the elements of ACE and how the constructs there might be useful in the boost libraries. Note that the current proposal borrows much from ACE design constructs: portability layer, acceptor, connector, and multiplexor (reactor in ACE). That said, ACE is very large and quite difficult to learn. This isn't hard to understand since it encompasses constructs for network programming, threads, and more. It took 2 300 page books just to just scratch the surface. The partitioning at the source code level is weak since everything basically resides in /ace. I see this as a major impediment to using ACE and is to be avoided by prospective boost libraries. In addition to size, the ACE implementation leaves some other things to be desired. It is over 10 years old -- ported to all sorts of platforms. The implementation is a literal MACRO hell. ACE doesn't take as much advantage of the standard library as we would expect of a boost library. It also doesn't leverage C++ features like namespaces and exceptions as we just expect of boost libraries. So I agree that we should look there for major design elements and not implementation approaches. Some other things about ACE: It has been ported to a myriad of platforms and is used extensively in commercial application development because of it's open licensing and general utility, portability, and the open source Object Request Broker (TAO) which is built on top. ACE has been developed by literally hundreds of volunteers and has had the benefit of commercial funding. In short, I find it unlikely that in the near term any set of boost libraries will replace it for someone that is interested in writing a network server. And I don't think that we should have 'competing' or 'replacing' ACE for all applications as our goal. Rather, I think we focus first on what is needed to do basic network programming -- especially for 'simple tasks'. For example, I need a client to go retrieve a web page or send some information to a server. These kinds of tasks are now extremely common and needing the entire ACE library just to do this is just wacky. So in summary, I think we should focus the Boost.Socket effort on what is currently described as 'level 1 - OS platform layer' and 'level 2 - basic connectivity layer' leaving multiplexing for later. I'm sure this will be controversial with some, but it seems to me that this is the only reasonable approach for a boost library daring to tread into a complex domain. I think that we need to look at boost::thread and boost::filesystem as examples of this approach. Dave A wrote: > >From what I've heard, the ACE architecture is highly interdependent, > with everything depending on everything else. There /might/ be > something to be gained by looking at its interface, but I would > approach it with caution. I don't think it is as interdependent as it might appear at first since the overall design is actually quite structured. However, since it is packaged as a single library you are pretty much stuck with the whole enchilada. Jeff _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost