You are viewing a plain text version of this content. The canonical link for it is here.
Posted to c-dev@xerces.apache.org by James Berry <jb...@criticalpath.com> on 2000/08/04 18:42:27 UTC
DOMString Agenda?
Can we have a bit of a discussion about an agenda
within Xerces for DOMString? There's a lot of
discussion concern with this all in Xalan, but
much of it stems from Xerces.
Potential Choices:
(1) Leave it alone
(2) Move to a basic_string derivitive
(3) Modify to address performance issues
(may be addressed in (4)).
(4) Some hybrid approach:
(a) Begin adding basic_string support (and
usage thereof) with eventual
goal of typedef'ing to basic_string altogether.
(b) Changes to reference counting contract in
order to support
use of DOMString results without
requiring cloning.
(c) Rethinking/tuning threading contract.
(d) Standardizing XMLCh size to 16 bit
Disussion? Direction? Plans? Flames?
-jdb
--
/************************************
James D. Berry
mailto:jberry@criticalpath.com
http://www.criticalpath.com
voice:503 222 2922
fax:503 222 3020
************************************/
Re: DOMString Agenda?
Posted by Dean Roddey <dr...@charmedquark.com>.
> (1) Leave it alone
>
> (2) Move to a basic_string derivitive
>
I am against this. Lets face it, the 'standard' libraries are one of the
least standard standards out there. I've yet to hear of anyone who used the
STL stuff who didn't have lots of cross platform and cross compiler
problems. The current system is quite easy to support on multiple platforms.
Also, bringing in the need to support (and have present) the STL stuff just
for strings would be a huge waste. The only thing that would justify it
would be to use it completely. But, that would make the previous point even
worse. STL is woefully unstandard.
> (3) Modify to address performance issues
> (may be addressed in (4)).
>
No one would argue that any code shouldn't perform better I guess.
> (c) Rethinking/tuning threading contract.
What problems do you have with it now?
> (d) Standardizing XMLCh size to 16 bit
>
This would be very counter productive IMHO. It would be better to fix the
parser to use UCS-4 on those platforms where that is the native wide
character type. Changing the parser such that its output is not compatible
with local wide strings APIs is really a questionable goal, in fact its not
a goal at all really that I can see.
--------------------------
Dean Roddey
The CIDLib C++ Frameworks
Charmed Quark Software
droddey@charmedquark.com
http://www.charmedquark.com
"You young, and you gotcha health. Whatchoo wanna job fer?"
RE: DOMString Agenda?
Posted by James Pearson <ja...@computer.org>.
Hi jdb,
I vote for #1.
It won't be long before there's a significant amount of application code
with Xerces out there that will require support - hopefully (right?). Most
developers like to keep up with the latest revs - for performance gains, new
features, etc. So, if you're talking about making changes to DOMString that
will break my existing, debugged, hard-earned code - then I say "forget it".
(I'm still 'adjusting' to the latest formatting/encoding features of rel.
1.2 - see my recent posting here.)
I think some sort of backward compatible, or dual scheme approach, that
keeps the old while allowing the new to be phased-in or recoded-to when it's
convenient, would work. But what a mess to implement.
Thanks for listening to my <cents>2</cents>,
Jim
-----Original Message-----
From: James Berry [mailto:jberry@criticalpath.com]
Sent: Friday, August 04, 2000 12:42 PM
To: xerces-c-dev@xml.apache.org
Subject: DOMString Agenda?
Can we have a bit of a discussion about an agenda
within Xerces for DOMString? There's a lot of
discussion concern with this all in Xalan, but
much of it stems from Xerces.
Potential Choices:
(1) Leave it alone
(2) Move to a basic_string derivitive
(3) Modify to address performance issues
(may be addressed in (4)).
(4) Some hybrid approach:
(a) Begin adding basic_string support (and
usage thereof) with eventual
goal of typedef'ing to basic_string altogether.
(b) Changes to reference counting contract in
order to support
use of DOMString results without
requiring cloning.
(c) Rethinking/tuning threading contract.
(d) Standardizing XMLCh size to 16 bit
Disussion? Direction? Plans? Flames?
-jdb
--
/************************************
James D. Berry
mailto:jberry@criticalpath.com
http://www.criticalpath.com
voice:503 222 2922
fax:503 222 3020
************************************/
---------------------------------------------------------------------
To unsubscribe, e-mail: xerces-c-dev-unsubscribe@xml.apache.org
For additional commands, e-mail: xerces-c-dev-help@xml.apache.org