API Design: Handling of Guid vs. String

[tthiery]

I am right now trying to port the LEGO Wireless Protocol from .NET Core+WinRT to Blazor+WebBluetooth. This project seems to be currently the only WebBluetooth library for Blazor in the ecosystem.

I got confused when using Guids with the library

• Navigator Filters and other API are taking strings and not System.Guid. I know they are union types in JavaScript but in C# the handling of the API is very inconsistent. Other interfaces take actual Guids. I would ask for a design consistency.
• The Guids used in the WebBluetooth API have to be lower case. This is highly disruptive for normal C# devs (which would assume that either guid or guid.ToString() would simply work. Since the Bluetooth spec speaks of UUID, assuming an API using Guids should work despite WebBluetooth internal (mis)behaviors.

I guess it is a tradeoff whether to follow the WebBluetooth / JS design guidelines or the .NET Coding Guidelines. However, since there is no literal translation of commands (e.g. RequestDeviceAsync is connecting the device unlike the requestDevice JS operation) I would argue the .NET Framework guideline is a better choice to follow.

[EngstromJimmy]

Sounds like a fun project! I'm happy to help test it when you feel ready.

The reason I use strings and not guids is because the Web Bluetooth api can take strings as well. You can as an example do this:

var bytes = await navigator.ReadValueAsync(device.Id, "device_information", "firmware_revision_string");

What would you suggest, add a ToLower()? I think its a better idea to support guid and string in the API (please prove me wrong).

[tthiery]

For the Guid usage, within the shim code, a .ToLowerInvariant helps.

Regards the union data type: Should not that be a case for overloads?

[EngstromJimmy]

I think you have valid points. The first version was just to get something that works out in the community. I have addressed your suggestions and just uploaded a new Nuget package 0.0.2.

Please keep me updated with your progress =)

[tthiery]

I am stuck now with something beyond your (awesome) library. The LEGO PoweredUp device shoots a series of characteristic notifications immediately after connect. Even straight in JavaScript I am not fast enough setting up the notification listeners. I posted it to StackOverflow and hope someone will come up with some magic. IMHO, this is a design issue of LEGO side

[tthiery]

Just as another heads up: My question lead to an Issue in the WebBluetooth WG. Lets see how that ends ;)