I am interested in a Boost review of this library but suspect it is too large. It also overlaps with several existing boost components. But good to get further opinions.
I have read your last posts about your mega library. I'm interested on the kind of services the library could provide.
Perhaps MegaMessaging.lib?
I don't think people would spent time to inspect code without the Boost license that reinvent a lot of Boost libraries.
Sorry this is a little confusing. I can understand that Boosters will be less inclined to review a library that replicates some existing Boost components. Even if there is differentiation in the implementations I am resigned to the natural reluctance. But it is the sum of the parts that I have hopes for. I am willing to substitute reinventions with the appropriate Boost component as necessary. But you also mention the lack of a Boost license. Are you suggesting that all code offered for review must first hand over all rights? With some effort I can see justification for such a position but it leaves me (and others like me) with a difficult question.
Is there more documentation that the one contained on the link?
Yes but they are internal and extremely abstract. Peer reviews have suggested that these docs are probably not useful to users of the library. This library is an internal development. It is/will be used for product development. All the materials that you have seen were created at the expense of that development. And in the full knowledge that organizations such as Boost are less than likely to accept/adopt/integrate.
Could you show how the objects read the messages?
I'm not entirely sure what you are asking for. If I give a quick description perhaps you can highlight the section of interest? Objects are read by calls to codec_base::decode (lhc/codec_base.h). This is a virtual member that invokes the parsing implementation for whichever encoding type has been selected. Those implementations are generally a combination of lexical analysis (manually defined state tables) and actual parsing (simple stack manipulation for simple encodings, BNF tools for XML). Some related files are; * lhc/lean_text.h - declaration of Lean Text codec incl. output of that encoding. * lhc/word_parser.h - declaration of simple object parser * lhc_parser/word_markup.h - declaration of Word Markup (XML) codec incl output You can see how the lex and parse activity is managed in codec<T>::decode (lhc/codec.h). The whole process is made much more complex by the requirement for encoding independence. The solution is based on a stack that deals with (top to bottom) I/O of objects, buffering strategy and block device operations. The proper use of codecs is demonstrated in load (lhc/codec_object.h). But maybe your question is about how messages are detected on network connections, routed and dispatched? There is a thread object (lhc/socket_processor.h) that is dedicated to the handling of winsock FD_xxxx events and client winsock calls (listen, connect). It arranges for creation of session objects (lhc/socket_transport.h) that manage actual I/O. These objects are the network equivalent of the objects created by load for reading of flies. Both socket_transport and load (actually file_transfer::read_existing) ultimately call codec_base::decode. The dispatching of messages once they reach an object is demonstrated in the samples, e.g. sample-t_trip-inter-process-client\trip_controller.cpp. Does this roadmap help to focus your question?
Note that async is already used by a library under developement https://svn.boost.org/trac/boost/wiki/LibrariesUnderConstruction#Boost.Async
Ah OK. Will check this out (pun unintended).
A last point, to request interest on a library maybe the best could be to put "Request for interest" in the title, and show some motivating use cases.
Yes. Thanks for this. I will try out a few ideas while also considering your other points. The level of interest so far is a concern. Not unexpected but silly to ignore. Cheers, Scott