>> Noone knows as there is no consensus on how the library's >> architecture should look like. There are different approaches and >> proposals at Boost Wiki and in the sandbox but what's still missing >> is the big picture. As far as there are no ideas of how to get a >> reasonable model which incorporates different things like >> blocking/non-blocking/multiplexing/asynchronous/extensible... there >> won't be much progress. I've been thinking about that and hope to >> come up with an idea in a few days.
Actually I think we have come a bit on the design and could churn out something that could be use as a foundation for further discussion. I think whats missing is the reactor part for event notification using eg select. Actually I think that a select based reactor would be a sensible next step to make a proof of concept on the current design. > 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? I have looked at that direction while experimenting with the design in the sandbox at least for the asynch parts (proactor, asynch_acceptor, asynch_data_socket). And for the layer 2 standard multplexing of events via select i think the reactor pattern would fit. I don't have a problem with a borrowing concepts from ACE or POSA2 (Pattern Oriented Software Architecture 2) to implement boost.sockets layer 2, do any other of you have strong opinions on patterns used in ACE and mentioned in POSA2? /Michel _______________________________________________ Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost