-
Notifications
You must be signed in to change notification settings - Fork 428
NET Core strategy for IoT and more #358
Comments
.NETStandard is about expressing API that is available natively in many .NET implementations. The path to getting in the standard is first having that API, then having it in many places, then graduating to be required as part of the standard. Nothing is preventing brand-new API from being invented and implemented above this, but still be available everywhere. Look at System.Collections.Immutable or Newtonsoft.Json. That's the first step. I'd recommend moving this to CoreFx as a feature request for the API and note that you'd like it to also work on other frameworks as an out-of-band package. Once that becomes ubiquitous and mature API we can consider adding it to the standard. /cc @terrajobst |
I agree with @ericstj that if you would like to pursue this further it would be good to create an API proposal in corefx and get it added there in .NET Core and then we can consider it for .NET Standard in the future. |
Thanks for your feedback. It sounds reasonable how you think about .net standard. But sometimes it would be good ta take a leadership role, by proposing API, which should/could become a part of standard. This way community and companies could get more motivated to implement such APIs. Regarding IoT APIs set. We already have a set of APIs related to BLE, various sensors and GPIO. They all are implemented as a part of Windows IoT Extensions and available for UWP only. |
The Windows IoT Extensions are WinRT API's. You can write .NET code against them and still be a .NET Standard library. You would just only run on Windows because you are calling WinRT API's. One could imagine writing an abstraction leveraging those API's on top of WinRT and other API's on Linux or any other relevant IoT platform. In any event, those should all be able to be built on top of .NET Standard and do platform lightup to call the right API's depending on the platform they are running on. |
This is not a first time that somebody is asking for GPIO or similar to be supported in .NET core. It is also clear that .NET core is originally designed as a cloud first platform.
In my opinion we should seriously think about extending of .NET standard in appropriate way, to be able to support additional (extended) scenarios.
When I say GPIO I think about some specific probably most popular scenario at the moment. But this is not enough. We should provide some standardized way to implement any hardware related scenario.
For example, get processor temperature, read some sensor data, deal with BT et., etc..
If we have a motivation to be cross-platform, we will have standardize it in more general way. Right now, Imagine how helpful is to use .NET core on cross platform to implement something like this.
Today, in such kind of scenarios is .NET core is not very helpful, because it breaks on critical implementation part related to hardware. It looks as Node seem to be on the better way.
This is why I posted this "issue"/suggestion in "standard" repo. :)
The text was updated successfully, but these errors were encountered: