[snip]
Scott, using Boost to implement your own library will help to get more people interested in your library (at least for inclusion in Boost). This probes that you know which parts od Boost can be reused without reinventing the wheel, the suers needs to lears less things, as he possible already knows the reused parts.
I appreciate the value of what you say. It's perhaps interesting to note that I have been developing this library since before most of the "parts ... Boost" have existed, i.e. initially at least there was no actual avoidance of Boost components. Also, in some cases I had goals that were simply not included in Boost implementations. Boost.Serialization does not have runtime encoding selection. Boost.Serialization will never deploy seamlessly inside an async messaging system without additional framing work. Apparent re-inventions are not always re-inventions. Lastly there is also a broader issue. My collection of parts cooperate inside a framework, i.e. my unique id mechanism has requirements imposed by the runtime type system and my discriminated variant has requirements from the encoding layer of my I/O stack. Boost does not have anything like such a framework. In fact Boost components have a strong "generic" flavor about them. They tend to shrug off any requirements coming from a specific architectural view. I have observed the review process for several parts of Boost that seemed relevant to my library. In some cases I have offered input from the perspective of my library, including input on singletons, statechart (i.e. fsm), logging and I suspect, asio. Except for singletons that input is not reflected in Boost components. I think all parties involved behaved perfectly reasonably and that the resulting components are strong, generic software tools. But they do not meet the requirements of my framework. The process of Boost-ifying my library should be interesting.
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.
No this is not absolutely necesary. Reviewing a lot of code that is not released with BSL could be a waste of time if at the end you decide to not propose your library to Boost. The fact you release it under BSL is already a good sign that you want to make it part od Boost.
Thanks Vicente, this makes good sense. [snip]
It is up to you to make interest. This is part of the work to get a library on Boost. My experience is that this part is even harder than implementing your library, but the feedback will make your library much better.
Understood. I'm still considering the use cases.
Another thing that helps could be to been able to build and test your library with Boost.Build (bjam) so we can evaluate the portability of your library (If I have understood you have only tested using a windows platform with MSVC). Note that a library could start to be considered as portable when it is implemented on at least two platforms (Win|Linux) with two compilers (gcc|msvc). In addition there are some Boosters that have no access to MSVC, so this people will be unable to run the example programs.
Also understood. Cheers, Scott