Adriano, > External interfaces is my worry, not intl libraries.
Ah, I missed the point then. > 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. The message metadata is a part of the prepared statement. While the underlying request could be shared among attachments, this does not necessarily mean that all the wrappers and helpers should. So per-attachment buffers don't look as something terribly wrong to me, provided that they're needed for purpose. > 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. It does look more consistent at the first glance. But there's a semantical difference between getting something like a message (which is different every time) and getting metadata info (which is constant). So it could be OK to have them processed differently. Just my two cents. Dmitry ------------------------------------------------------------------------------ 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
