[libxml++] Revisting the Glib::ustring vs. std::string issue.



Hi,

I have read all the previous posts regarding the use of Glib::ustring and std::string for use with libxml++.  I have even read the bug and the associated patch.  I understand Murray's point of view and agree with him from a package maintainer's point of view.

However, I would really like to move forward with one part of the proposed change, and am willing to produce an updated patch.

The change that David Yan submitted on 2007-02-10 had two changes.  The first was to rename all of the use of Glib::ustring to xmlpp::string.  This, I believe, should be adopted in the mainline as it has no functional change, and would serve to minimize the number of locations the external glibmm libraries are referenced.  The second change was to allow the underlying type of xmlpp::string to be selected by the installer.  If only this change is integrated with the code, the second change can be easily done by anyone who really needs it.

I would like to use libxmlpp, but my target system doesn't have (nor will it) any glib libraries.  That dependency is a non-starter.  However, like many other libraries, I am willing to patch this one -- I purpose build all of the third-party libraries I use, I don't use the system version.  The inclusion of the first of David Yan's changes (updated to match the current code, of course) would allow be, and anyone else, to make my patch much MUCH smaller.

I understand the desire to keep the current api, and appreciate that, as Murray said, it would be too easy for the wrong version of a package to be released with some OS, causing havoc.  That said, what do you think of including the first part of those changes into the main-line?

Thanks!

David


NOTICE: This e-mail contains information that may be confidential and proprietary. If you are not the intended recipient, any disclosure or other use of this e-mail or the information contained herein or attached hereto may be unlawful and is strictly prohibited. If you have received this e-mail in error, please notify the sender immediately and delete this e-mail without reading, printing, copying or forwarding it to anyone. Thank you for your kind cooperation.
AVIS : Ce courriel contient des renseignements qui peuvent etre confidentiels ou de propriete industrielle. Si vous n'etes pas le veritable destinataire, la diffusion ou l'usage de ce courriel, des renseignements qu'il contient ou des documents qui lui sont joints pourrait etre illegal. Il est donc strictement interdit de les diffuser ou de les utiliser. Si vous avez recu ce courriel par erreur, veuillez en aviser l'expediteur immediatement et veuillez le supprimer sans le lire, l'imprimer, le sauvegarder ou le diffuser. Merci de votre aimable collaboration.




[Date Prev][Date Next]   [Thread Prev][Thread Next]   [Thread Index] [Date Index] [Author Index]