jamesmunns / bbqueue

Hi, I was reading the code and noticed this comment:

Lines 36 to 38 in 640312d

    
           //! For bbqueue, the sender doing the encoding and the receiver doing the decoding 
        
           //! will always reside on the same platform, meaning we CAN make these non-portable 
        
           //! assumptions for the sake of performance/simplicity.

Is still a desire to favor performance (or simplicity) over cross platform operation? My - very naive - guess would be that the benefits of being single-platform are minimal. Not being cross-platform was unexpected for me and, had I not seen this, I would have been unpleasantly surprised by these issues. The pointer size issue does seem to be one concern with the current code. Another might be endianness - which is not much discussed much. Both could be adjusted in future releases (e.g. by using the vint64 crate, also mentioned in the code).

I am asking because I was thinking about using bbqueue to communicate between an embedded device and a PC, but this would violate the design assumptions described above.

If this design decision is still relevant, it may be worth pointing this out in the readme, because otherwise bbqueue seems like a nice way to communicate between platforms and I could imagine I would not be the only person to have that idea.

Another idea would be to abstract out the particular framing code and let the user choose between platform-specific performance and cross-platform interop.

Clarification: I am referring to the packet framing.

Hey @astraw, that comment means that bbqueue will only ever run on one platform: e.g. you have the Producer and Consumer halves on the same machine. Because the vusize is a hidden implementation detail that is never exposed to the user, it is totally safe to use bbqueue to talk between two machines!

What I mean by that comment:

              interrupt sending bytes out
                  over the serial port
                          |
 application creating     |
     data to send         |
        |                 |
        v                 v
[         embedded system          ]    [      PC system      ]
[ [bbq producer] => [bbq consumer] ] => [                     ]
[                                  ]    [                     ]
                 ^                   ^
                 |                   |
         `vusize` lives here         |
                                     |
                            bytes sent over a serial
                              port, in order. Frame
                            information is not sent over
                               the wire.

I hope this clears things up, let me know if not!

Edit: Added more info to the diagram.

Also, if you want to expose framing information over the wire, that is something you have to handle separately. For example:

If you are using a radio to send "packets" that have a size, that can represent the frames
If you are using a stream like a serial port, you can use a portable technique like COBS to expose these frames

However, that is outside of the domain of bbqueue.

@astraw check out the updated description in https://github.com/jamesmunns/bbqueue/pull/62/files.

As I said here, there is no issue using BBQueue to communicate between different kinds of systems, and the warning you saw in that file was mostly to prevent people from copy/pasting that implementation into a context where portability IS relevant, such as serialization/deserialization code between two different machines :)

Thanks for the clarification.

	//! For bbqueue, the sender doing the encoding and the receiver doing the decoding
	//! will always reside on the same platform, meaning we CAN make these non-portable
	//! assumptions for the sake of performance/simplicity.

Why does bbqueue target only a single platform?