On 03/07/14 16:45, Dimitry Sibiryakov wrote:
> 07.03.2014 13:18, Alex Peshkoff wrote:
>> On 03/07/14 15:14, Dimitry Sibiryakov wrote:
>>>       There is no difference if you store offset got from a virtual 
>>> function or a pointer got
>>> from other virtual function. In any case you'll have to perform 
>>> "buffer+offset" operation
>>> every time you use the same or different buffer. With pointer you can 
>>> receive new pointer
>>> only if buffer is changed. No difference between 
>>> "buffer+Metadata.getOffset(i)" and
>>> "Buffer.getData(i)" which has the same "buffer+Metadata.getOffset(i)" 
>>> inside.
>> Certainly, such interface specially oriented on a case when buffer is
>> not changed may exist.
>> But offset-oriented interface is required anyway: remember, we get it
>> from server having no buffer at all.
>     After prepare we get from server a metadata-only object. There is no need 
> in offsets in
> this object. Offsets are not a part of metadata at all, IMHO, and their 
> presence in
> IMessageMetadata is an architectural mistake.

You suggest to add a special roundtrip to get them?
I get _all_ metadata at once, and I do not understand why you call it 
"architectural mistake".

>> I.e. it will be duplication, which is not good in low level API.
>     What duplication you are talking about?

Offsets + pointers.
If offsets are removed certainly no duplication.

>>>       Exactly the same way: one just pass next (descendant of) IBuffer to 
>>> fetch() and there
>>> is no need to worry how this IBuffer keeps information internally. Default 
>>> TPlainBuffer
>>> can keep all values in single piece of memory, someone can invent 
>>> TScatteredBuffer for any
>>> reason and so on. Polymorphism will allow server code to work with all of 
>>> them.
>> No. To make server work message's buffer should always be plain.
>> Certainly, we may rework server code and learn it to work with non-plain
>> buffers, but I see no reason to do it.
>     So do I. But could you point to an example of code where plain data 
> buffer is a
> requirement?

Currently - a lot of. dsql.cpp:map_in_out() for example.

>> This requires exactly same thing - learn server to work with non-plain
>> message buffer.
>     Or to explicit using of plain buffer class which data is copied to if 
> necessary.
>

No, last thing I want to add in new API is one more data copying.


------------------------------------------------------------------------------
Subversion Kills Productivity. Get off Subversion & Make the Move to Perforce.
With Perforce, you get hassle-free workflows. Merge that actually works. 
Faster operations. Version large binaries.  Built-in WAN optimization and the
freedom to use Git, Perforce or both. Make the move to Perforce.
http://pubads.g.doubleclick.net/gampad/clk?id=122218951&iu=/4140/ostg.clktrk
Firebird-Devel mailing list, web interface at 
https://lists.sourceforge.net/lists/listinfo/firebird-devel

Reply via email to