[libxml++] Vote: templates everywhere v. Glib::ustring

[Murray Cumming Comneon com]

I can't decide completely, and whatever I decide is likely to upset someone,
so I'd like to take a vote. See the bottom of this email for some more
thoughts.

What I want you to do:
  Everyone has had time to comment and I do understand all the issues so I
would like everyone to respond with a simple A, B, or C vote - 1 only
please. I _will_ ignore any additional comments - this is a vote so further
discussion, if necessary, can happen in a separate thread. If you need more
information before voting, please do look at the archives, particularly from
the last few days:
http://sourceforge.net/mailarchive/forum.php?forum_id=12784
The maintainer(s) will probably respect the outcome of this vote but, then
again, we might choose to ignore you completely - it's only fair to warn
you.

*** The Vote:
Libxml++ 1.0 will use std::string. But to support UTF8 (Unicode) properly in
its API a future version of libxml++ should ...

A.
use Glib::ustring, which is already used by gtkmm. 

Advantage:
  Glib::ustring is very much like std::string and you can use a std::string
wherever you see a Glib::ustring, if 
  you like. Here is some more documentation on Glib::ustring:
  http://www.gtkmm.org/gtkmm2/docs/reference/html/classGlib_1_1ustring.html
Disadvantages:
  - Libxml++ would then depend on glibmm 2.4 and glib. Libxml++ would not
need gtkmm.
  Glib is on every linux distribution and will be on Solaris by default very
soon.
  - Theoretical loss of performance when using a different string class,
because data must be converted.

B.
Use templates almost everywhere. The string class would be a template
parameter for each class - e.g. We would provide typedefs for common uses
such as
typedef xmlpp::Node<Glib::ustring> xmlpp_ustring::Node
typedef xmlpp::DomParser<Glib::ustring> xmlpp_ustring::DomParser
and
typedef xmlpp::Node<QString> xmlpp_qstring::Node
typedef xmlpp::DomParser<QString> xmlpp_qstring::DomParser


Advantage:
  Allows use of whatever string class you like.
Disadvantage:
  - Almost all code in libxml++ would be in a template in a header. Libxml++
would no longer really be a library so 
  it would have no concept of ABI. You would have to recompile your
application to benefit from even minor 
  implementation bug fixes. 
  - The API would be less clear because people would actually use the
typedefs but would need to look at the 
  actual templates to see the methods. The situation is the same for std::
iostreams but people tend not to use so
  many classes together - libxml++ is a hierarchy of related classes.

C.
do whatever you like. I don't care.


More thoughts:
- Personally, I think the templates-requiring-recompilation-of-apps problem
is a major one. It's not suitable for gtkmm so I doubt it's suitable for any
other library. Even if people vote overwhelmingly for B I _might_ choose to
fork libxml++ after 1.0 and do a Glib::ustring version. If I do this I would
probably not be involved with the templated fork. This is a possibility - I
haven't made a decision yet. I would find this decision easier because I
think the templated fork would exist only for people who want to use Qstring
and I think that most of those people would prefer to use Qt's own XML
parser instead.

Murray Cumming
murrayc usa net
www.murrayc.com