Re: Sockets, Streams, and Element_Arrays: Much confusion

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

On 2023-01-01 00:41, Simon Wright wrote:
> "Dmitry A. Kazakov" <mailbox@dmitry-kazakov.de> writes:
> 
>> My advise would be not to do this. It is wasting resources and
>> complicated being indirect when 'Write and 'Read are
>> compiler-generated. If you implement 'Write and 'Read yourself, then
>> why not calling these implementations directly. It just does not make
>> sense to me. I always wonder why people always overdesign
>> communication stuff.
>>
>> Build messages directly in a Stream_Element_Array. Use
>> system-independent ways to encode packet data. E.g. chained codes for
>> integers. Mantissa + exponent for real numbers. If you have Booleans
>> and enumerations it is a good idea to pack them into one or two octets
>> to shorten the packets. All this is very straightforward and easy to
>> implement.
> 
> It has to depend on the design criteria.
> 
> If you need something now, and it's not performance critical, and you
> have control over both ends of the channel, why not go for a
> low-brain-power solution?

Because it is still much simpler (and safer) than record layouts.

> On the other hand, when faced with e.g. SNTP, why not use Ada's
> facilities (e.g. [1]) to describe the network packet and use unchecked
> conversion to convert to/from the corresponding stream element array to
> be sent/received?

Well decoding NTP query from Stream_Element_Array takes 2 statements 
(extracting two big-endian 32-bit numbers). You can check the 
implementation here:

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

which is under-zero brained (:-)) compared to dealing with definition of 
record layout and bit orders you suggest.

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