On 03/18/13 16:56, Dmitry Yemanov wrote: > 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.
IMessageMetadata is refcounted interface. I.e. it's lifetime is not restricted to statement, attachment, something else. As long as needed user keeps counter > 0, and strings returned by getField() are stable. Or may be I did not understand the question? What is intl specific here? >> 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. > Certainly. ------------------------------------------------------------------------------ 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
