Re: [boost] [async] messages threads and networks

Subject: Re: [boost] [async] messages threads and networks
From: Scott Woods (scott_at_[hidden])
Date: 2010-04-25 12:41:46

[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