Jim Starkey wrote:

> My high priority feature list for Firebird 3 is very short:

> 1. Two level name space (aka schemas)
> 2. Long identifiers (128 characters)
> 3. UTF-8 only ODS

What about...
4. SMP friendly

? Perhaps this just being assumed, since I seem to remember
that it was one of the drivers for when you started working on
Vulcan. The lack of this feature is becoming more and more of
an issue for new Fb implementations.


What I actually wanted to discuss more was UTF-8...

Are we sure that we should not seriously consider UTF-16?

Windows NT4 and later uses UTF-16. Qt's QString class is also
UTF-16. From memory ICU is too, but someone here will know for
certain. What are Java strings?

If these commonly used interfaces use UTF-16, is there not
some potential benefit to be had by using a string class that
matches? This could avoid much conversion back and forth,
when the client and server are using compatible forms.

Costs...

- increased disk space (probably irrelevant)

- potential endian issues (already exist but if client and
server use different forms then conversion benefits hoped
for by using UTF-16 are lost).

- probable increased network volume (effect and significance
depends on the actual language used in the database)

- more work and bigger impact on the code to implement

- incompatible with old API


If the most common interfaces are UTF-16 it seems to me that it
could be useful to handle strings as UTF-16 so that the benefit
can be achieved when possible. When the benefit cannot be
achieved the client can request (or perform its own) UTF-8 or
endian conversion.

The relative cost/benefit is really just guessing on my part,
others may have a better idea. I just know, for example, that
in a Qt project I am involved with I can see strings constantly
being converted to/from its internal UTF-16 representation as
I interact with the Fb API. It seems like a waste, but perhaps
the alternative would be worse.


--
Geoff Worboys
Telesis Computing