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.

> I.e. it will be duplication, which is not good in low level API.

   What duplication you are talking about?

>>      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?

> 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.

-- 
   WBR, SD.

------------------------------------------------------------------------------
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