mirror of
https://github.com/tauri-apps/rfcs.git
synced 2026-01-31 00:35:24 +01:00
78 lines
3.6 KiB
Markdown
78 lines
3.6 KiB
Markdown
- Feature Name: (fill me in with a unique ident, `my_awesome_feature`)
|
|
- Start Date: (fill me in with today's date, YYYY-MM-DD)
|
|
- RFC PR: [tauri-apps/rfcs#0000](https://github.com/tauri-apps/rfcs/pull/0000)
|
|
- Tracking Issue: [tauri-apps/tauri#0000](https://github.com/tauri-apps/tauri/issues/0000)
|
|
|
|
# Summary
|
|
|
|
One paragraph explanation of the feature.
|
|
|
|
# Motivation
|
|
|
|
Why are we doing this? What use cases does it support? What will developers, end-users and core-devs gain from this? What is the expected outcome?
|
|
|
|
# Guide-level explanation
|
|
|
|
- Explaining the feature largely in terms of examples.
|
|
- If applicable, provide sample error messages, deprecation warnings, or migration guidance.
|
|
- If applicable, describe how this feature can be taught to existing and new Tauri developers.
|
|
|
|
# Reference-level explanation
|
|
|
|
The technical portion of the RFC. Please explain in detail:
|
|
|
|
- How the feature interacts with other features.
|
|
- That it is reasonably clear how the feature would be implemented.
|
|
- Any corner cases should be covered by examples.
|
|
- Does this require stale dependencies to be forked? What is the long-term impact on core-developers? Does this introduce additional maintenance load?
|
|
|
|
The section should return to the examples given in the previous section, and explain more fully how the detailed proposal makes those examples work.
|
|
|
|
## Platform Considerations
|
|
|
|
Tauri works across a wide variety of platforms (Operating Systems, Architectures, Hardware Configurations). Please explain:
|
|
- If applicable, how this feature interacts with different platforms and whether some platforms introduce special behavior.
|
|
- If this feature can only be supported on a subset of platforms, explain why.
|
|
|
|
## Security Considerations
|
|
|
|
Tauri is a very security conscious project. Please explain in detail:
|
|
- How does this feature impacts the security of Tauri apps.
|
|
- If applicable, what design decisions you have taken to increase the security of this feature and Tauri apps at large.
|
|
- If it's clear that this feature will require the addition of new dependencies, how this feature impact Tauris risk of supply chain attacks.
|
|
|
|
## Performance Considerations
|
|
|
|
How will this feature impact the performance of a Tauri app?
|
|
|
|
## Community Considerations
|
|
|
|
How does this impact community libraries, tools and other work? Does this invalidate existing tutorials and learning materials?
|
|
|
|
# Drawbacks
|
|
|
|
Why should we *not* do this?
|
|
What are the limitations of this approach?
|
|
|
|
# Rationale and alternatives
|
|
|
|
- Why is this design the best in the space of possible designs?
|
|
- What other designs have been considered and what is the rationale for not choosing them?
|
|
- What is the impact of not doing this?
|
|
- If this is a language proposal, could this be done in a library or plugin instead?
|
|
|
|
# Prior art
|
|
|
|
Discuss prior art, both the good and the bad, in relation to this proposal.
|
|
A few examples of what this can include are:
|
|
|
|
- For community proposals: Is this done by some other community and what were their experiences with it?
|
|
- For other teams: What lessons can we learn from what other communities have done here?
|
|
- Papers: Are there any published papers or great posts that discuss this? If you have some relevant papers to refer to, this can serve as a more detailed theoretical background.
|
|
|
|
# Unresolved questions
|
|
|
|
- What parts of the design do you expect to resolve through the RFC process before this gets merged?
|
|
- What parts of the design do you expect to resolve through the implementation of this feature before stabilization?
|
|
- What related issues do you consider out of scope for this RFC that could be addressed in the future independently of the solution that comes out of this RFC?
|