From mboxrd@z Thu Jan 1 00:00:00 1970 X-Spam-Checker-Version: SpamAssassin 3.4.4 (2020-01-24) on polar.synack.me X-Spam-Level: X-Spam-Status: No, score=-1.9 required=5.0 tests=BAYES_00 autolearn=unavailable autolearn_force=no version=3.4.4 Path: eternal-september.org!reader01.eternal-september.org!feeder.eternal-september.org!aioe.org!.POSTED!not-for-mail From: "Dmitry A. Kazakov" Newsgroups: comp.lang.ada Subject: Re: protobuff for Ada Date: Wed, 2 Jan 2019 11:02:10 +0100 Organization: Aioe.org NNTP Server Message-ID: References: <177bddd8-297e-4c5f-85aa-31cd694e68b4@googlegroups.com> <71d4373a-d8f7-448e-90cf-ea700c783030@googlegroups.com> NNTP-Posting-Host: i065DRYuysvTI4qVnaNkyg.user.gioia.aioe.org Mime-Version: 1.0 Content-Type: text/plain; charset=utf-8; format=flowed Content-Transfer-Encoding: 7bit X-Complaints-To: abuse@aioe.org User-Agent: Mozilla/5.0 (Windows NT 10.0; WOW64; rv:60.0) Gecko/20100101 Thunderbird/60.3.3 X-Notice: Filtered by postfilter v. 0.8.3 Content-Language: en-US Xref: reader01.eternal-september.org comp.lang.ada:55163 Date: 2019-01-02T11:02:10+01:00 List-Id: On 2019-01-02 07:57, G. B. wrote: > Dmitry A. Kazakov 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