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

Reply via email to