(Breaking) API changes | Part 2

[Tederean]

Unfortunately the merge turned out a bit messy. I have now adapted lib.rs as announced in my other pull request. Let's continue the discussion here.

We can make HashableHString obsolete btw by updating the windows crate to .59.

[sidit77]

We can make HashableHString obsolete btw by updating the windows crate to .59.

That's great. I couldn't update to 0.58 before because it broke the async integration.

My problem with None is that it is ambiguous in this case. None because the device has no serial number or None because this feature isn't supported.

I'm not sure if these two cases have a meaningful difference. In the end both prevent you from obtaining the serial number. In general I would like to keep the platform specific differences in api surface as small as possible. I really dislike it when I successfully build something on one platform and when I try to compile the same program for another and it fails because some functions from my "cross-platform" dependency simply vanished. I feel like all core functions should be available on all platforms with a somewhat consistent behaviour. (Except for really obvious cases such as into_native_type functions or extension traits modules).

I really don't think it's a good idea to withhold the handles/IDs/paths from the developer.

I see your point, maybe we can move these converter functions into DeviceId? I.e something like into_device_path, into_device_guid, and into_registry_entry_id?

We could do it that way, that was my idea at first too. And then I realised how many avoidable panic situations this creates if you just let it go. For the Struct what Reader and Writer holds you generate following panic abilities

I also thought about that. However, I feel like for common usecase of either [Write request, Wait for reply] or [Wait for event, Write response] kind of "sequential" operations having one object that represents the device feels better to me than having two, implicitly connected, objects. I have to think about it a bit more.

[Tederean]

This line lists only devices that where previously allowed by request. I cleared permissions and my list is empty.

https://developer.chrome.com/docs/capabilities/hid?hl=en

To open an HID connection, first access a HIDDevice object. For this, you can either prompt the user to select a device by calling navigator.hid.requestDevice(), or pick one from navigator.hid.getDevices() which returns a list of devices the website has been granted access to previously.

I think we still will need an additional enumeration by criteria function after all.

[sidit77]

Yes, but if you call requestDevice with an empty list it will simply list all available devices in the permission popup. Providing the filter is simply a UX improvement that limits the popup to relevant devices.

[sidit77]

So I finally found some time to experiment a bit. I think this is currently my favourite design for handling the splitting of reader and writer. It should pretty much be your design, except that I moved the read/write functions to a trait and implemented said traits for (Reader, Writer)

I also experimented a bit with putting the backend behind a trait to better express the various auto-trait requirements for the various functions. Putting the backend behind a trait would also allow for having multiple backends enabled at the same time and doing runtime backend detection/fallback. I'm a bit worried about "infecting" everything the the B generic but that doesn't seem to be too much of an issue so far.

[Tederean]

That looks good. 👍

[Tederean]

Hello, i've decided to temporarily halt my work on WebAssembly. There are numerous issues to be tackled to make my implementation compatible with Async-HID. For now, I'd like to focus on other things. I wanted to ask if you need help with splitting the device into Reader & Writer. I'm also working on a crate that I would like to publish, but it relies on our new features which are not yet available on crates.io for async-HID.

[sidit77]

I'm sorry for the delay, but my work has been a bit busy the last month and weekends are over way to fast. I feel like it should still be January.

First things first, do you only need the win32 implementation or also the reader/writer split? I don't think I'll need help on the Reader/Writer front as it should be mostly copy-and-pasting stuff into the new "framework". If I remember correctly your design goals for the API change were the split Reader/Writer and access the the platform specific identifier, right? Or did I miss something?

[Tederean]

First things first, do you only need the win32 implementation or also the reader/writer split?

The current status of the Main branch would be completely sufficient for my concern. Would you release a new crates version for this?

If I remember correctly your design goals for the API change were the split Reader/Writer and access the the platform specific identifier, right?

That is correct, I have viewed the source code in the other branch and find it appealing.

[sidit77]

I just released version 0.2.0 of this crate. It should soon appear on crates.io.