Hi Soares,
I am an undergraduate student from the National University of Singapore and I am interested to take part in this year's GSoC with the Boost community.
Welcome! This is quite possibly the most comprehensive summary of a Boost discussion by a prospective GSoC student I've ever seen. Be sure to include this in your proposal as part of the background research (or a summary thereof).
I think there are several options that I can choose for my project: 1. To use Chad Nelson's code as base, try to incorporate other ideas proposed in the mailing list, integrate with Boost.Locale, and make it Boost quality to submit for review. If this option is chosen, I wish that Chad Nelson can be my mentor.
This seems feasible. Unfortunately, I don't know if Chad is available or willing to be a mentor.
2. To start a new code base, gather and compile ideas suggested in mailing list, final design decisions made by me and my mentor but not the community (to keep the project going on fast), make it Boost quality and submit for review.
I have a feeling that this will be a part of any project that you propose.
3. To start the boost::string project, where another better string is reinvented and fix all the weaknesses of std::string.
I think that this project may end up being a minefield. Everybody has their favorite string characteristics and whatever you string you eventually implement, will eventually fail somebody's requirements :)
4. Adopt different proposal, and improve on existing project such as Boost.Unicode [2] or Boost.Locale [3] such that it really solves the encoding awareness problem.
This also seems feasible. Was there any consensus on why std::string could or could not be parameterized with UTF-specific character traits? That seems, on the surface, like a possible solution. I was following the discussions but not as closely as others :)
I hope to get feedback from you on what should I really focus on in this project.
Hopefully, one of the participants in those discussions will be able to provide better feedback than I can. I think that one thing you should consider in your proposal is how you actually want to use your library. Consider trying to design your interface from a user perspective. I think that there is sometimes a tendency to focus on the technical aspects of a library, and It's easy to forget the end goal of writing a library: so somebody else can use it. Please don't let a lack of communication dissuade you from submitting a proposal. This list can be high traffic and its easy to miss good posts. Best regards, Andrew Sutton