[Interest] QCanBusDevice inheritance

[Blasche Alexander]

Hi,


>Thanks for your response but I still don't get why QIODevice has been
>discarded for CAN while it is used for QUdpSocket.

>First, frames can always be divided into bytes, there length is an
>integer multiple of byte. If you are talking about the fact that
>fields within a frame are not 8 bits longs (identifier can be 11),
>this should be handled by the underlying CAN library.

The QIODevice architecture was not a good fit for CAN bus. The API must enable the user to interpret the various frames received on the bus. In addition to the payload, each frame may come from different sources, has different types and other attributes. This means that the API requires at least an abstraction on frame level. For each new frame that you send you may adjust the frame attributes as well.

This is considerably different from a QIODevice based architecture where you generally open a connection to a remote entity and once the connection is established you merely keep exchanging payload. After all you don't set a new IP for each UDP datagram. There is no requirement to dissect the incoming data stream on the backend either. We generally copy the raw data to a socket.

Another inefficiency of the QIODevice approach would be that each frame would have to be serialized to a QByteArray on the user API side just to be unserialized on the backend side again. I have yet to see a backend API that doesn't deal with a frame based API. There is simply nothing gained.

Another argument, the frame based API serves as an input gate. We can make assumptions about data format to be send by the API user as the user has to fit it into a QCanBusFrame. How should a backend react to an arbitrary data stream coming from the user? We have to find all the frame details in it before we send it further on. Hence a QIODevice API invites "frame input errors" which is not very user friendly.

I hope this helps to understand the reasons for the change.

--
Alex
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.qt-project.org/pipermail/interest/attachments/20150909/8f2f7bc0/attachment.html>