diff --git a/proposals/0000-template.md b/proposals/0000-template.md index d9ba2a8..5e9c030 100644 --- a/proposals/0000-template.md +++ b/proposals/0000-template.md @@ -1,38 +1,66 @@ -# RFC 0000 - Template Mode - -## Goals - -1. Create RFCs -1. ?? -1. Profit - -## Diagrams - -Here is an ASCII diagram: - -``` - ╔ ═ ═ ═ ═ ═ ═ ═ ═ ═ ═ - ║ - ║ BitPackedArray - ║ - ╚│═ ═ ═ ═ ═ ═ ═ ╤ ═ ═ - │ │ - │ │ - │ │ - │ │ - │ │ - │ │ - │ │ patch - │ │ indices ╔ ═ ═ ═ ═ ═ -┌─────▼─────┐ ├─────────────▶ ArrayRef ║ -│░░░░░░░░░░░│ │ ╚ ═ ═ ═ ═ ═ -│░░Buffer░░░│ │ -│░░░░░░░░░░░│ │ patch -└───────────┘ │ values ╔ ═ ═ ═ ═ ═ - encoded └─────────────▶ ArrayRef ║ - ╚ ═ ═ ═ ═ ═ -``` - -We can have links, like https://github.com/vortex-data - -BUT, we can also have [**LINKS**](https://vortex.dev) or [__links__](https://docs.vortex.dev) +- Start Date: (today's date, YYYY-MM-DD) +- RFC PR: [vortex-data/rfcs#0000](https://github.com/vortex-data/rfcs/pull/0000) +- Tracking Issue: [vortex-data/vortex#0000](https://github.com/vortex-data/vortex/issues/0000) + +## Summary + +One paragraph explanation of the proposed change. + +## Motivation + +What problem does this solve? Include concrete use cases where possible. + +- What specific use cases does this enable or improve? +- What workflows or operations are painful, slow, or impossible today? + +## Design + +Describe the proposed design in enough detail that someone familiar with Vortex could implement it. This should cover: + +- New or modified APIs, traits, or vtable entries. +- How this interacts with existing components (encodings, layouts, scan, file format, etc.). +- Key implementation details and corner cases. +- Why is this the best approach in the space of possible designs? +- Which crates are affected and how the dependency graph changes, if at all. + +Use code examples and diagrams where they might help. + +## Compatibility + +- Does this change the file format or wire format? Is it backward/forward compatible? +- Does this break any public APIs? If so, what is the migration path? +- Are there performance implications? + +If there are no compatibility concerns, briefly state why. + +## Drawbacks + +- Why should we _not_ do this? +- What is the maintenance cost of this change? +- Does this add complexity that could be avoided? + +## Alternatives + +- What other designs were considered and why were they rejected? +- What is the cost of **not** doing this? +- Is there a simpler approach that gets us most of the way there? + +## Prior Art + +How have other systems solved this or similar problems? Consider: + +- Other columnar formats (Parquet, Arrow, etc.). +- Database internals (DuckDB, DataFusion, Velox, etc.). +- Relevant academic papers or blog posts. + +This section helps frame the design in a broader context. If there is no relevant prior art, that is fine. + +## Unresolved Questions + +- What parts of the design need to be resolved during the RFC process? +- What is explicitly out of scope for this RFC? +- Are there open questions that can be deferred to implementation? + +## Future Possibilities + +What natural extensions or follow-on work does this enable? This is a good place to note related ideas that are out of scope for this RFC but worth capturing.