[Interest] QCanBusDevice inheritance

[Blasche Alexander]

>> 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