On 09/17/2014 03:23 PM, Stephen Kelly wrote:

>> most date/time users don't use this - but a few do.  Is serialization a
>> prerequisite for date/time?  which users are we talking about?  One can't
>> win here.  If you distribute serialization with every use of date/time
>> you're distributing too much.  If you don't, you'll be failing to ship
>> functionality which some users need.  What is the solution here - make two
>> libraries out of date/time? or what?
>
> The solution is to make serialization low-cost to depend on, so that
> depending on it is not a problem. That is exactly what I am recommending.
> The current problem with serialization is that it is expensive in terms of
> needless dependencies. My recommendation does a lot to solve that for
> serialization.

Stephen,

speaking purely as a person who used serialization in the past,
I'm not sure I understand what you propose *exactly*. I thought that unless you
include XML archive headers, serialization does not actually pull in Spirit headers.

So what's your proposal exactly, since "extracting an xml_archive library from serialization"
is not entirely clear to me.

>> b) created as a separate library module

If that's your proposal, I would be -1 on this, if anybody bothered to care about my opinion. In particular,
that would mean that any changes to serialization library that affect XML archives and other parts would
happen in two different repositories, with no obvious way to relate per-repository changes.

MPL maintainers too a different approach to this, by creating two submodules inside a
single repository - which seems a bit better to me.

- Volodya



_______________________________________________
Unsubscribe & other changes: http://lists.boost.org/mailman/listinfo.cgi/boost