On 03/11/14 17:39, Dimitry Sibiryakov wrote: >> What may be discussed is should we document exact order of fields in the >> message or probably let user create arbitrary one. If we decide to use 2 >> approach - them offsets really should travel over the wire. > No, please. Read again: documenting of data buffer format will engrave it > in stone, you > won't be able to change it even if you want. > IMHO, right way is to hide field order behind interface.
Sorry, but field _order_ should better match order of output fields in select for output messages and order of '?' parameters in input messages. If we add some method to have another order of fields in messages, that's a good way to get crazy ourself and make users crazy. >> This is the simplest solution, but requires a lot of virtual calls per >> every row. Therefore we decided not to use it. > Not virtual calls is a bottleneck. Memory copying and data scattering are > much more > unpleasant. It depends upon what data do you send/receive. For various numeric formats data copying is just few asm commands. But the most important is that most typical use of API (creating data access components) anyway supposes placing data in some buffer of records. And new APi is oriented first of all on making this operation as simple as possible. >>> To accomplish that, every module should work with objects >>> (interfaces) coming from >>> outside without attempts to guess their implementation and using only their >>> API. >> And where do we guess? We use some documented suggestions. > You use undocumented Yes, documentation is not ready yet... > requirement to follow fb_utils::sqlTypeToDsc() behavior which is > not optimal but compatible with old versions. It puts too tight restrictions > on plugins > and components authors. As I've already mentioned for people using c++ there are wrappers doing exactly what you want. And that wrappers provide both excellent performance and mentioned by you service when accessing data. What a problem? >> Well, I agree - it's OK to add a check for offsets returned by >> IMessageMetadata when converting it to BLR. > Arghhh... Check not. Use them. I don't know REMOTE internals, but > shouldn't integer > data to be converted to network byte order before sending to a wire? If yes, > it anyway > must be done in field-by-field basic, and there is no reason for fixed-format > continuous > buffer on entrance. > In remote layer messages are really parsed field by field, but this is not the only possible way to go. Our protocol traditionally provided sending message buffers 'as is' between same architecture machines (not less than 99% of data transfers). It was turned of cause it had problems with sending strings over the wire - too many repeated data. But if sometimes we add data compression to remote - a method with sending messages 'as is' can become actual once again. And please - do not forget about embedded access. ------------------------------------------------------------------------------ Learn Graph Databases - Download FREE O'Reilly Book "Graph Databases" is the definitive new guide to graph databases and their applications. Written by three acclaimed leaders in the field, this first edition is now available. Download your free book today! http://p.sf.net/sfu/13534_NeoTech Firebird-Devel mailing list, web interface at https://lists.sourceforge.net/lists/listinfo/firebird-devel
