>> 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
_______________________________________________
Interest mailing list
Interest@qt-project.org
http://lists.qt-project.org/mailman/listinfo/interest
