
Vladimir Prus wrote:
Robert Ramey wrote:
Bryce has re-implemented the xml_loader in terms of the the current version of spirit. This is something that people have asked for and he has stepped up and done it. He has coordinated with me and has run all the serialization tests with his new code on his own machine. I've endorsed trunk access privileges for him (weeks ago) but as far as I know nothing has happened. I would have hoped to see his code tested in the test matrix by now.
What's wrong with applying a patch yourself?
Ahhh - that's a very good question. I have a very good reasons for not doing this. First, it's not just a "patch". It's recoding the xml_parser in the latest version of spirit. Second, it's not just "applying the patch". It's also monitoring how the tests go on all the platforms in the matrix. It's often the case that some or other combination of os, C++ compiler, standard library implementation or whatever fails and then one has to spend an unexpected amount of time tracking down the problem. It's also quite possible that this is not the end of it. When it get's unleashed to users, it's possible that other issues will arise. I see this as unavoidable since spirit pushes the envelope of what some compilers can do. So, I could say I don't have the time right now - and it would be true. I could also say I have more urgent issues regarding the library which should be addressed first - and that would also be true. I could also say I work with pottery barn rules - "you break it - you bought it" (pottery barn is a chain of stores in the US which sells pottery and other fragil objects). That would also be true. But that's not my reason. My real reason is that I want to make my job smaller by permitting those who have an interest in the library to take responsability for the aspects that interest them. This will make my job smaller and increase the amount of effort which will be expended in in proving the library. This "hands off" attitude has resulted in the MPI version of serialization, now Bryce's effort, and now someone want's to take responsability for the utf-8 conversion facet. It has also permited numberous other libraries to add thier own serialization support without any effort or conflict with what I'm doing. Regretable, I haven't been able to accept all proposals since sometimes they conflict with my view of what the library should be, but I've tried to accomodate the enhancements that I can. I also have a "To Do" list at the end of the documentation which anyone is free to work on. There are some things I reserve for myself alone. e.g. fixing my most arcane bugs, refining interface and concepts, etc. Robert Ramey