Re: protobuff for Ada

["Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de>]

On 2019-01-02 07:57, G. B. wrote:
> Dmitry A. Kazakov <mailbox@dmitry-kazakov.de> wrote:
> 
>> *If* you are OK without semantics then there is no need to introduce
>> this mess. Use Ada stream attributes and simply read and write what you
>> want and how you want. It is clean, easy, fast and 100% Ada.
> 
> What kind of stream do you write for your partners in business?

Stream of octets.

> Three of
> them have different needs than you WRT data and none of them is using Ada.

They still can read and write the stream. You are confusing description 
of a protocol with the implementation of.

The OP suggested having descriptions in protobuff and partial 
implementation generated from that. It is a bad idea.

-------------------------------
BTW, it is very easy to write things like protobuff straight in Ada with 
Simple Components

    http://www.dmitry-kazakov.de/ada/components.htm#17.2.1

This feature is rarely used because, as I said, the concept is too 
limited and constraining if not wrong altogether.

Here is a small example. Consider an example in protobuff:

    message Person {
       required string name = 1;
       required int32 id = 2;
       optional string email = 3;
    }

This direct Ada code:

    type Person is new State_Machine with
       Name  : String_Data_Item (Max_String_Length);
       ID    : Unsigned_32_Data_Item;
       Email : String_Data_Item (Max_String_Length);
    end record;

Thanks to Ada's "introspection" that is all. It will be read or written 
by the connections server automatically. On the packet receipt callback, 
you get values like Person_Session.ID.Value. Before sending a new packet 
you assign Person_Session.ID.Value. Note, this is Ada 95, no fancy stuff.

I didn't show here alternation for using optional fields because the 
transport level representation would be different anyway. Which is the 
point actually. Such key details are all left unspecified in the 
protobuff "description" above along with endianness and other encoding 
issues. Yet exactly these details are essential in practice where the 
protocol is already defined. Present or not bits might kept combined in 
the message header, special values of integers are reserved to indicate 
exceptional states and so on and so forth. And, again, no semantics 
whatsoever, just buckets of bits.

-- 
Regards,
Dmitry A. Kazakov
http://www.dmitry-kazakov.de