Subject: Re: [boost] Interest in a FIX Protocol Library?
From: Robert Ramey (ramey_at_[hidden])
Date: 2015-01-15 16:10:37
Sergey Cheban-2 wrote
> I think that it is a good idea to support these standards in the Boost.
> Unfortunately, I think that FIX is far too domain-specific. As a boost
> user, I'm not against mentioning boost-licensed domain-specific
> libraries somewhere at the Boost web site but I don't think that these
> libraries should be included into the default boost distribution. The
> reasons are:
> 1. The library size does matter.
The above is predicated that Distribution of Boost Libraries will continue
indefinately to be distributed as a complete package. Our recent efforts
including modularization, reduction of dependencies, etc. will eventually
result in a deployment model in which acceptance into boost and
deployment will be decoupled. Users will install subsets of boost that
they actually use. This might result in distributions with names like:
Boost.Core - iterators, ranges, etc...
Boost.Legacy - stuff which is obsolete for modern compilers but is
still needed by some people - BOOST_FOREACH, BOOST_TYPEOF, etc.
So I think that trying too keep boost small - though attractive - doesn't
look forward to the future. I think the main challenge to Boost and C++
in the future is to find a way to produce better quality libraries.
> 2. The boost community has to support everything that is included into
> the boost library. What if a maintainer of some library abandons it? For
> a general-purpose library, there are chances that someone will take
> responsibility for it. For a domain-specific library, such chances seem
> to be negligible.
True - and we need to find a way to address that. But that's no reason
for keeping the library small or letting it grow - it's a different
-- View this message in context: http://boost.2283326.n4.nabble.com/Interest-in-a-FIX-Protocol-Library-tp4670976p4671205.html Sent from the Boost - Dev mailing list archive at Nabble.com.
Boost list run by bdawes at acm.org, gregod at cs.rpi.edu, cpdaniel at pacbell.net, john at johnmaddock.co.uk