On 18/03/2013 07:23, Dmitry Yemanov wrote:
> I would split this topic into different ones: charsets/collations and
> plugins.
>
> Formerly, I was against the UTF8-only idea. Now I'm getting closer to
> accepting it, but some issues require serious discussion. I think 95% of
> the engine could be made natively UTF8 but charsets must remain in some
> (properly isolated) layers. For example, the database or field level
> charset declaration could be used as a hint to optimize storage of
> non-ASCII strings. And I doubt we can throw away the attachment charset
> concept, so charsets could also migrate to the client library.
>
> From another side, one may expect that a declared charset should act as
> a constraint, validating the input to fit the given charset. And if we
> keep having charsets declared for everything including variables, then I
> don't see how we could clean the engine from the INTL burden :-(
>
> As for INTL plugins, our practice shows that virtually nobody develop
> their own intl2 libs. So perhaps we should drop that interface/plugin
> thing altogether and link everything statically. The only way of
> defining custom charsets (besides providing patches to have them
> built-in) could be something derived from the ICU. However, if we'd be
> able to make the engine almost-UTF8 with optional charsets, it would
> mean that our binaries will carry the unneeded code for those using only
> UTF8 in their apps.
External interfaces is my worry, not intl libraries.
Current we have things as:
const char* IMessageMetadata::getField(IStatus*)
This is not intl-safe, as engine would need to maintain per-attachment
buffers. I do not even know if this is ok from API POV.
We need some guidelines to write a consistent API.
Maybe a simple change could make things better:
void IMessageMetadata::getField(IStatus*, char* buffer, unsigned
bufferSize)
This also has drawbacks (need to copy bytes back and forth), but we need
to be consistent and check if API do not introduce problems with
existing functionalities.
Adriano
------------------------------------------------------------------------------
Everyone hates slow websites. So do we.
Make your web apps faster with AppDynamics
Download AppDynamics Lite for free today:
http://p.sf.net/sfu/appdyn_d2d_mar
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel