On 03/18/13 17:38, Adriano dos Santos Fernandes wrote:
> On 18/03/2013 10:19, Alex Peshkoff wrote:
>> 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 getF
On 03/18/13 21:11, Adriano dos Santos Fernandes wrote:
> On 18/03/2013 13:25, Alex Peshkoff wrote:
>> On 03/18/13 17:35, Adriano dos Santos Fernandes wrote:
>>> MyStatusImpl status;// inline
>>> apiFunction(&status); // status methods are called only if a error is
>>> throw
>>> status.check()
On 18-03-2013 17:30, Vlad Khorsun wrote:
>
>Again, MasterInterfacePtr will return cached IMaster pointer passed by
> plugin manager which loads current plugin module.
>
Got it, thanks. So the problem I mentioned first does not exist.
Adriano
---
18.03.2013 19:11, Adriano dos Santos Fernandes wrote:
...
>>> And this is what I saw it's required to support, but do you think the
>>> current code allows it?
>> As far as I know - yes, it does.
> I'm not sure I understand you. More below.
Let me try to explain it
> , as the engines will
On 18/03/2013 13:25, Alex Peshkoff wrote:
> On 03/18/13 17:35, Adriano dos Santos Fernandes wrote:
>> MyStatusImpl status;// inline
>> apiFunction(&status); // status methods are called only if a error is
>> throw
>> status.check()// inline
>>
>> So I have doubts about the provider manner
On 03/18/13 17:35, Adriano dos Santos Fernandes wrote:
> On 18/03/2013 07:46, Alex Peshkoff wrote:
>> On 03/18/13 03:40, Adriano dos Santos Fernandes wrote:
>>
>>> - IStatus (1):
>>>
>>> It's not clear what is this when interacting with external code.
>>> Provider functions clears it when entering
On 18/03/2013 10:19, Alex Peshkoff wrote:
> 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 q
On 18/03/2013 07:46, Alex Peshkoff wrote:
> On 03/18/13 03:40, Adriano dos Santos Fernandes wrote:
>
>> - IStatus (1):
>>
>> It's not clear what is this when interacting with external code.
>> Provider functions clears it when entering but no other function does
>> it. It's not clear what callers s
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
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
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
18.03.2013 11:59, Dmitry Yemanov wrote:
> If not and if we'd be agree to pay a memory penalty, UCS4
> or whatever else could be used instead.
Memory penalty will be the case only if UTF8 strings are kept with real
length.
Otherwise buffers are allocated with the same size 4*max_length.
--
18.03.2013 14:45, Dimitry Sibiryakov wrote:
> What's the point of using UTF8? ICU internally works with UCS4, so for every
> comparsion
> or other operation engine will have to convert UTF8 to UCS4 and then back.
> Such waste of time.
I was implying that a C string (zero terminated) compatibili
18.03.2013 11:23, Dmitry Yemanov wrote:
> I think 95% of the engine could be made natively UTF8
What's the point of using UTF8? ICU internally works with UCS4, so for every
comparsion
or other operation engine will have to convert UTF8 to UCS4 and then back. Such
waste of time.
--
WBR,
On 03/18/13 03:40, Adriano dos Santos Fernandes wrote:
>
> - IStatus (1):
>
> It's not clear what is this when interacting with external code.
> Provider functions clears it when entering but no other function does
> it. It's not clear what callers should do to check states.
All called functions
Adriano,
I'll comment only the parts I have something to say.
> - Character sets and plugins:
>
> At some time in the past, Jim wanted to deprecate charsets and use just
> UTF-8. I was opposite to this idea, and I probably still am, but it's a
> fact that character sets and plugins are a difficul
Hi!
First, this is not a solution proposal nor critiques for previous
decisions. I just want to express the problems I'm seeing.
Firebird codebase is becoming more and more difficult to change/extend.
Some not good code/concepts are being introduced everywhere, added with
some bad previous code/c
17 matches
Mail list logo
