> >> [...] > >> 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? > > >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.
This has been my experience too. It was the primary reason that we rejected ACE for our socket needs on the project I am on at the moment. Unfortunately there didn't seem to be too many alternatives for portable, robust and well thought out socket based libraries (that we could find, anyway). This is why I am so keen to see a good boost implementation (so far we have written our own simple solution on top of a handful of wrapper classes we dug up from somewhere). Although it would be great to see boost.sockets out there sooner rather than later I would hate to think that it was rushed for the sake of getting it out. The scarcity of good socket libraries, especially ones that don't bind you to a framework, suggests (to me at least) that this is not a trivial thing to achieve successfully. FWIW, I personally still thing that the POSA2 patterns that ACE uses are basically sound (not that I am any sort of authority in this area). Of course a layered approach is critical to the framework-busting goal, but I don't think anyone disputes that. Just my tuppence worth, [)o IhIL.. _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost