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
