> 11.04.2011 15:44, Vlad Khorsun wrote:
>>> Not quite so. "Easy to write" (for me) means "use well documented API
>>> which has enough
>>> examples of usage". Nothig from this is applied to the new API.
>>
>> Do you have completed API somewhere ? Where do you read that API is
>> already completed and
>> documented ? This mailing list is for developers of Firebird, and we talk
>> about work in progress here.
>
> Usually development of such things as _public_ API comes in backward
> direction:
> specification first, implementation later.
Probably you missed that we are not creating *new* API calls (or new
ideology) there. We are creating
object-based interface for the existing API and looking forward how to create
it in efficient and backward
compatible way.
> Breaking of this rule used to lead to a mess.
> Look at _already implemented_ API extension - fb_ping() and point me to
> it's
> description in doc/ folder, please. None. Ok, let's take much older extension
> -
> fb_interpret(). Also only one mention in RN, no parameters description, no
> usage in
> examples.
Did you noted descriptions of much more important new API's, such as
fb_shutdown ?
Where are your ticket at the tracker, btw ?
> Any reason to think that new API will be more fortunate? I don't have it.
So, what do you do here ? Just argue about the things you even not going to
use ? Wasting
our time with useless questions ? (if one ask a question and not going to read
answer - this is
useless question, isn't is ?).
>>> And, BTW, what "additional access layers" you have on mind? Y-valve?
>>
>> I speak about "drivers", such as IBPP, IBX\FIB+, ODBC, etc
>
> You know that I don't use them.
Yes, i know. And what ?
>>>> Call overhead also will be less than with ISC API.
>>>
>>> How big performance gain do you expect from it?
>>
>> I don't know. When it will be ready, you are welcome to test it.
>
> So, "call overhead also _will_ be less" is just a hope and new API may be
> slower than
> old one, right?
When i said "Call overhead also will be less" i meant exactly "Call
overhead also will be less".
Is it clear ?
>>> AFAIK, CPU time wasted in old API
>>> serialization is microscopic in comparison with network or disk interaction
>>> time.
>>
>> Its not about serialization. Its about converting of data between
>> formats and calls thru many
>> levels of internal functions.
>
> AFAIU, new API is based on the Message API (at least in this thread is
> discussed
> exactly wrapper around BlrMessage). There is only one transformation between
> XSQLDA API
> and Message API, and it includes no data conversion, just copying it. Exactly
> as the new
> API does. Where profit will come from?
You wiil be able to use message-based DSQL API in a more easy way then old
XSQLDA-based
DSQL API. Oh, no, sorry. You are not going to use new API :-D
Regards,
Vlad
PS When i started to answer your questions i thought that you really not
understand something
obvious for us. I was wrong. Now i see you just mocks of us.
------------------------------------------------------------------------------
Xperia(TM) PLAY
It's a major breakthrough. An authentic gaming
smartphone on the nation's most reliable network.
And it wants your games.
http://p.sf.net/sfu/verizon-sfdev
Firebird-Devel mailing list, web interface at
https://lists.sourceforge.net/lists/listinfo/firebird-devel
