Beman Dawes wrote:
While this is an interesting proposal, it appears to me to be several years worth of work. How would you structure the first summer's work? Would you aim at breadth (a prototype covering the whole) or depth (production quality work that concentrates on one aspect)?
As there have been multiple attempts at a boost.unicode library in the past, and they all failed (at least in the sense that they didn't result in any usable unicode library as part of boost), I would like to see any further attempts at this to learn from this experience. To me, it suggests that a more incremental approach is needed, where the focus is on small self-contained chunks of functionality that can be reviewed and integrated into boost quickly. (Obviously it's also important to keep the big picture in mind, but aiming too high is a clear recipe for failure.) (One aspect of this is that it may be important to recognize that the API won't necessarily be 'right' in the first iteration. Having to aim for the ultimate (generic) unicode API upfront (knowing that any future API changes will meet heavy resistance) may actually hinder progress.) Regards, Stefan -- ...ich hab' noch einen Koffer in Berlin...