Of course if we decide to follow Peter's suggestion and make the change, it is, as always, who is going to do the work. It would be ridiculous to lay this all on John. I am volunteering to help if needed, and I imagine Peter would also, so it would be a matter of finding those people with the time to make this happen if we decided to do it.
I think that since this is effectively Config.v2 we're talking about here, and since I have absolutely no time for this anyway, then if it's decided that this is the way forward, it would be better if the maintenance baton were handed on to someone else at this point: BTW this is absolutely not me "chucking my toys out of the pram", just a realistic assessment that I have neither time nor much inclination for this at this time. I would obviously try and provide constructive criticism / help as I can. I'm also frankly amazed that the design has worked as well as it has for so long - there's an awful lot of hard one knowledge encoded in the Config headers, and I hope that can be retained. BTW, if we're looking at a redesign, and potentially a lot of churn in client code, I think I'd like to see at least a mini-review before any change: Boost.Config is so central to everything and the effects of substantive change potentially so damaging if we get wrong, that some extra-special caution is required in this particular case IMO. Best, John. --- This email has been checked for viruses by AVG. http://www.avg.com