Project scope overlap

[krwq]

Hello,

Can you look at https://github.com/dotnet/iot/pull/1393. I think there may be some overlap with what we're trying to do.

[alonf]

Hi, Thanks for introducing this. They took the same approach for Windows IoT devices for handling the device hardware while we wanted to have a cross-platform easy C# code generation library. I agree that we can use both solutions for Windows IoT based devices. Do you think that we need to converge? We still want to support the scenario of having C# running on any supported device with the Azure IoT hub.

[krwq]

@alonf dotnet/iot is cross-platform. I'd actually say Raspbian/Linux specifically is supported slightly better than Windows at this point. There is also some work in progress to have nano framework support (with some prototypes already working).

The attributes themselves are meant for code generation but codegen is still in the prototype phase (the prototypes are not public though yet), I can introduce you to some more details on the approach we took if you'd like to have a quick chat on IM (there is some overlap but not entirely). We've placed the attributes temporarily inside the hardware library but in the end I expect it to be separate Nuget package (I'd like the attributes to remain stable so for prototyping phase where there might be some changes we wanted to have them together with the devices as it will be easier to adjust).

I suspect we'll move them to a separate Nuget package in couple of months but we need to stabilize first as we do not want to introduce any breaking changes after they ship.

The attributes I've introduced are meant to capture very simple model:

• Interface - any class (device) producing telemetry or having properties or commands
• Telemetry - some data which devices is producing by i.e. reading the sensor
• Properties - data related to the device which doesn't change without user's interaction, it may be writable
• Command - some action which can be run on the device

I.e. device can be HTS221 (relative humidity and temperature sensor), what it produces are two telemetries: RelativeHumidity and Temperature, the model will be described with attributes as seen here: https://github.com/dotnet/iot/blob/master/src/devices/Hts221/Hts221.cs

From there we cover couple of pieces:

• given the attributes and input class (class for which user wants to do the code-gen for) we produce model file in DTDL v2 format which is used by Azure Plug & Play - the model itself tries to be independent from the DTDL but that's our main scenario for now
• given the attributes we produce the project (instead of code generator we generate entire C# project) which creates IoT Hub client which sends data from the device to IoT Hub and it complies to the DTDL format it produced
  • output is a command line tool which takes connection string or device provisioning system connection string, the project can be adjusted manually to meet specific user requirements, but the idea is that you use the generator and immediately deploy this app on the device with the sensor (likely we will also have an option to generate a library so that more advanced scenarios can be covered)
• given the DTDL (note: this doesn't require attributes, any DTDL should work) we generate a C# project which reads data (telemetry) from IoT Hub assuming device is complying with the DTDL
  • output is a library which user can consume in their app

What I like about your approach is that you're doing code gen directly, the benefit is clear, the disadvantage of that is that many times user will want to customize generated code - of course you can provide set of knobs to cover most common scenarios but there is a benefit from users being able to edit what was code-gened (perhaps providing boths solutions would be a good idea to cover both easy & advanced scenarios).

I think the goals of this and our project are similar we just took different approach and it might be beneficial for us to join forces on that.