[Interest] QCanBusDevice inheritance

[Benjamin TERRIER]

2015-09-10 9:49 GMT+02:00 Blasche Alexander
<alexander.blasche at theqtcompany.com>:
>
>>> Another inefficiency of the QIODevice approach would be that each frame
> Hi,
>
>>> 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.
>>
>>I don't get why each frame would have to be serialized if
>>QCanBusDevice inherits QIODevice. The implementation of
>>QCanBusDevice::writeFrame() would not change. It would, on the other
>>hand, require to implement QIODevice::writeData() which would either
>>call QCanBusDevice::writeFrame() or directly the backend API
>>effectively doing some "unserialization".
>
> The question is how you get to the serialized QCanBusFrame in the first place.
>
> Based on your suggestion above the usual order of calls for a QIODevice based API across the stack is such that
>
> const char* serialized_frame = ...
> device->write(serialized_frame;
>  -> device->writeData(serialized_frame, size); // deserializes serialized_frame
>     -> device->writeFrame(frame) // based on your suggestion above
>
> How did the user create serialized_frame if not using some QDataStream operator that created it from QCanBusFrame? Surely you cannot expect the API user to create the data stream representing a frame from scratch but via QCanBusFrame?
>
> I am sorry all I see is artificially passing everything through a serialization process where the top and the bottom of the call series end up with the same QCanBusFrame. Then I may as well permit the user to directly call writeFrame(). And that's what we did.
>
> Let me ask you this, why do you want it to be a QIODevice? It's not because the Qt docs stating "The QIODevice class is the base interface class of all I/O devices in Qt", is it? For me the API just doesn't fit and that's reason enough for me to contradict the QIODevice documentation ;)
>
> --
> Alex

I do not object that the user can directly call writeFrame(). And I
agree that using the QIODevice API in such case would lead to an
unnecessary overload.

Nonetheless, I think that, as it has been done with QUdpSocket, adding
the QIODevice API to the existing CAN API would only make the Qt
framework more coherent. (It is just a matter of taste and policy.)

To be clear, I don't want the QCanBusDevice API to fit inside the
QIODevice API, but I would find it more coherent if QCanBusDevice
would offer the QIODevice API as a fallback ; the current CAN API
would still be public and the recommended way to use QCanBusDevice.

Benjamin