Skip to content
This repository has been archived by the owner on Sep 13, 2022. It is now read-only.

NET Core strategy for IoT and more #358

Closed
ddobric opened this issue May 20, 2017 · 4 comments
Closed

NET Core strategy for IoT and more #358

ddobric opened this issue May 20, 2017 · 4 comments

Comments

@ddobric
Copy link

ddobric commented May 20, 2017

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. :)

@ericstj
Copy link
Member

ericstj commented May 24, 2017

.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

@weshaggard
Copy link
Member

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.

@ddobric
Copy link
Author

ddobric commented Jun 23, 2017

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.
How about integrating them to standard and providing them as .net core?

@Petermarcu
Copy link
Member

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.

Sign up for free to subscribe to this conversation on GitHub. Already have an account? Sign in.
Labels
None yet
Projects
None yet
Development

No branches or pull requests

4 participants