Interrupt and bulk transfers are joined together and just called "transfers", control and isochromous are separate in functions and result types.
Some result types carry the exact same data (USBIsochronousInTransferPacket and USBInTransferResult, for instance).
interface USBInTransferResult {
readonly attribute DataView data;
readonly attribute USBTransferStatus status;
};
interface USBOutTransferResult {
readonly attribute unsigned long bytesWritten;
readonly attribute USBTransferStatus status;
};
interface USBIsochronousInTransferPacket {
readonly attribute DataView data;
readonly attribute USBTransferStatus status;
};
interface USBIsochronousInTransferResult {
readonly attribute DataView data;
readonly attribute FrozenArray<USBIsochronousInTransferPacket> packets;
};
interface USBIsochronousOutTransferPacket {
readonly attribute unsigned long bytesWritten;
readonly attribute USBTransferStatus status;
};
interface USBIsochronousOutTransferResult {
readonly attribute FrozenArray<USBIsochronousOutTransferPacket> packets;
};
Why not simplify this:
interface USBOutTransferResult {
readonly attribute TransferType type; // "isochronous", "interrupt", "bulk", "control"
readonly attribute FrozenArray<USBOutTransferPacketResult> packets;
}
interface USBInTransferResult {
readonly attribute TransferType type; // "isochronous", "interrupt", "bulk", "control"
readonly attribute FrozenArray<USBInTransferPacketResult> packets;
};
interface USBOutTransferPacketResult {
readonly attribute unsigned long bytesWritten;
readonly attribute USBTransferStatus status;
};
interface USBInTransferPacketResult {
readonly attribute DataView data;
readonly attribute USBTransferStatus status;
};
Yes this means that you would need to do result.packets[0].bytesWritten
for instance for a bulk transfer, but I don't think that should be much of an issue. It might be possible to have a shorthand like result.packet
as well.
As the endpoint type is fixed (unless reconfigured), I also think we can safely merge transferIn(octet endpointNumber, unsigned long length);
and Promise<USBIsochronousInTransferResult> isochronousTransferIn(octet endpointNumber, sequence<unsigned long> packetLengths);
to
Promise<USBInTransferResult> transferIn(octet endpointNumber, sequence<unsigned long> packetLengths);
A sequence with size more than 1 for non-isochronous transfers makes no sense and can just result in a failed promise, with an appropriate error.
I still like having controlTransferIn separate as it is really a special endpoint, but for that reason, it make sense to rename transferIn(..)
to dataTransferIn