Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Feature Request: implementation of crypto #178

Open
ibigbug opened this issue Jan 15, 2019 · 5 comments
Open

Feature Request: implementation of crypto #178

ibigbug opened this issue Jan 15, 2019 · 5 comments

Comments

@ibigbug
Copy link

ibigbug commented Jan 15, 2019

Hi Dart team,

Is there any plan for packages like crypto and encoding being implemented as part of the standard libs? As Dart will be running from "Server" side, so I guess packages like that will be very useful.

I'm trying to port the Golang implementation of those packages to Dart, but it's quite a huge amount of coding. So it will be awesome to hear that Dart will have packages like that as a part of stdlibs.

@zoechi
Copy link

zoechi commented Jan 15, 2019

I think this should be reported in dart-lang/sdk.
dart-lang/sdk#34452 might make it easy for server-side and Flutter.

@ibigbug
Copy link
Author

ibigbug commented Jan 15, 2019

I'm looking into the that issue, it's talking about FFI, but not actually any implementation of crypto related stdlibs, I'll assume those functionality will be addressed by calling another lang using FFI?

btw, sorry for putting the issue in a wrong place.

@zoechi
Copy link

zoechi commented Jan 15, 2019

FFI allows to call out to C libraries.

@kevmoo
Copy link
Member

kevmoo commented Jan 15, 2019

Not sure this is a language feature – @munificent @leafpetersen ?

@munificent
Copy link
Member

I'm not exactly sure where corelib issues go, actually.

But, to the original question, there is already at least one package in Dart for crypto and there is a core library for encoding. I'm not sure if they cover your use case or not.

There aren't any plans to move crypto into the core libraries, and I think that's a good thing. In general, being in the core libraries causes more problems than it solves. Core libraries are very hard to evolve over time, and users have little control over which version of the core libs they use. If a poor API design choice is made in a corelib, we're basically stuck with it forever for compatibility.

Packages are much easier to evolve over time, control the upgrade story for, and replace entirely when a new better package appears.

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

No branches or pull requests

4 participants