2019-02-22 17:00:13 +01:00
|
|
|
- Start Date: (fill me in with today's date, YYYY-MM-DD)
|
|
|
|
- RFC PR: (leave this empty)
|
|
|
|
- Kibana Issue: (leave this empty)
|
|
|
|
|
|
|
|
# Summary
|
|
|
|
|
|
|
|
Brief explanation of the feature.
|
|
|
|
|
|
|
|
# Basic example
|
|
|
|
|
|
|
|
If the proposal involves a new or changed API, include a basic code example.
|
|
|
|
Omit this section if it's not applicable.
|
|
|
|
|
|
|
|
# Motivation
|
|
|
|
|
|
|
|
Why are we doing this? What use cases does it support? What is the expected
|
|
|
|
outcome?
|
|
|
|
|
|
|
|
Please focus on explaining the motivation so that if this RFC is not accepted,
|
|
|
|
the motivation could be used to develop alternative solutions. In other words,
|
|
|
|
enumerate the constraints you are trying to solve without coupling them too
|
|
|
|
closely to the solution you have in mind.
|
|
|
|
|
|
|
|
# Detailed design
|
|
|
|
|
|
|
|
This is the bulk of the RFC. Explain the design in enough detail for somebody
|
|
|
|
familiar with Kibana to understand, and for somebody familiar with the
|
|
|
|
implementation to implement. This should get into specifics and corner-cases,
|
|
|
|
and include examples of how the feature is used. Any new terminology should be
|
|
|
|
defined here.
|
|
|
|
|
|
|
|
# Drawbacks
|
|
|
|
|
|
|
|
Why should we *not* do this? Please consider:
|
|
|
|
|
|
|
|
- implementation cost, both in term of code size and complexity
|
|
|
|
- the impact on teaching people Kibana development
|
|
|
|
- integration of this feature with other existing and planned features
|
|
|
|
- cost of migrating existing Kibana plugins (is it a breaking change?)
|
|
|
|
|
|
|
|
There are tradeoffs to choosing any path. Attempt to identify them here.
|
|
|
|
|
|
|
|
# Alternatives
|
|
|
|
|
|
|
|
What other designs have been considered? What is the impact of not doing this?
|
|
|
|
|
|
|
|
# Adoption strategy
|
|
|
|
|
|
|
|
If we implement this proposal, how will existing Kibana developers adopt it? Is
|
|
|
|
this a breaking change? Can we write a codemod? Should we coordinate with
|
|
|
|
other projects or libraries?
|
|
|
|
|
2021-05-03 17:26:51 +02:00
|
|
|
# How this scales
|
|
|
|
|
|
|
|
Does this change affect Kibana's performance in a substantial way? Have we discovered
|
|
|
|
the upper bounds before we see performance degradations? Will any load
|
|
|
|
tests be added to cover these scenarios?
|
|
|
|
|
2019-02-22 17:00:13 +01:00
|
|
|
# How we teach this
|
|
|
|
|
|
|
|
What names and terminology work best for these concepts and why? How is this
|
|
|
|
idea best presented? As a continuation of existing Kibana patterns?
|
|
|
|
|
|
|
|
Would the acceptance of this proposal mean the Kibana documentation must be
|
|
|
|
re-organized or altered? Does it change how Kibana is taught to new developers
|
|
|
|
at any level?
|
|
|
|
|
|
|
|
How should this feature be taught to existing Kibana developers?
|
|
|
|
|
|
|
|
# Unresolved questions
|
|
|
|
|
|
|
|
Optional, but suggested for first drafts. What parts of the design are still
|
|
|
|
TBD?
|