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

V4 Development: General strategy on how to fill in missing APIs #3298

Open
2 tasks
danielmarbach opened this issue Apr 24, 2024 · 5 comments
Open
2 tasks

V4 Development: General strategy on how to fill in missing APIs #3298

danielmarbach opened this issue Apr 24, 2024 · 5 comments
Labels
feature-request A feature should be added or improved. module/sdk-core p2 This is a standard priority issue v4

Comments

@danielmarbach
Copy link
Contributor

Describe the feature

I'm currently fiddling around with some performance improvements and for some cases I need to somehow polyfill certain missing APIs or attributes. For example in order to implement overrenting when doing stack allocations it might be beneficial to add SkipsLocalsInit. Another example are missing encoding extension methods that accept ReadOnlySpan.

Several of these cases can be poly filled by adding corresponding attributes or methods into the utils and that might be the teams preferred approach. On the other hand there are libraries like Polyfil or Polysharp that to some extend implement those workarounds already.

In order to proceed forward it would be great if the strategy for the v4 development branch would be documented somewhere. Additionally the team could potentially also set the LangVersion to a reasonable language version that the team wants to allow so that contributors have clear guidelines on what or what not to use.

Use Case

Contributing to v4 development but I guess these questions are anyway something the team on the v4 branch has to have answers for independent of whether someone contributes or not.

Proposed Solution

No response

Other Information

No response

Acknowledgements

  • I may be able to implement this feature request
  • This feature might incur a breaking change

AWS .NET SDK and/or Package version used

v4

Targeted .NET Platform

all

Operating System and version

all

@danielmarbach danielmarbach added feature-request A feature should be added or improved. needs-triage This issue or PR still needs to be triaged. labels Apr 24, 2024
@danielmarbach
Copy link
Contributor Author

To add an example. Here is a new URL encode method I quickly spiked danielmarbach@81d8586. Already there I'm missing proper GetBytes and GetString overloads for Netstandard that I would have to shim. I don't have SkipLocalsInit and I have discrepancy between TryGetValue and GetValueOrDefault.

@normj
Copy link
Member

normj commented Apr 24, 2024

@danielmarbach Agreed we need to get this documented. We haven't really talked too much about V4 yet other then the blog post announcing the drop in support for .NET Framework 3.5. Not trying to keep it a secret but we are taking care of some internal infrastructure changes right now to support both a V3 and V4. After that I was hoping to be more proactively public about V4. That being said don't let that stop you from contributing to V4. The main thing about V4 is it will be evolutionary not revolutionary so only breaking changes when necessary to make a better product.

To your immediate question about poly fills the SDK is still going to take a hard rule of avoiding taking on external dependencies. The SDK is too low level in most people's applications and dependencies we take can cause collection with versions customers use or we could be forced to make breaking changes due to the dependencies we don't control.

Using pragmas to target newer versions and leaving older versions using stock implementations is perfectly fine in the SDK. I'm not very interested in having pragmas with special implementations in older targets. I don't want to build up code we have to maintain for targets people are moving away from.

@ashishdhingra ashishdhingra removed the needs-triage This issue or PR still needs to be triaged. label Apr 25, 2024
@Dreamescaper
Copy link
Contributor

Dreamescaper commented Apr 26, 2024

@normj

To your immediate question about poly fills the SDK is still going to take a hard rule of avoiding taking on external dependencies. The SDK is too low level in most people's applications and dependencies we take can cause collection with versions customers use or we could be forced to make breaking changes due to the dependencies we don't control.

Both Polyfil and Polysharp are source-only dependencies, meaning that customers wouldn't even know that SDK uses them.

@danielmarbach
Copy link
Contributor Author

Absolutely what @Dreamescaper said. Essentially those are development time dependencies and will not be dependencies on the shipped product at all. So the risk here is probably more of a supply chain risk than anything else (which obviously requires considerations I get that)

@normj
Copy link
Member

normj commented May 10, 2024

I didn't realize the libraries were source-only dependencies. As you can call I haven't ever tried them before. Let me play around with them to get more familiar with them and then I will come back.

@ashishdhingra ashishdhingra added the p2 This is a standard priority issue label Jun 17, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
feature-request A feature should be added or improved. module/sdk-core p2 This is a standard priority issue v4
Projects
None yet
Development

No branches or pull requests

4 participants