-
Notifications
You must be signed in to change notification settings - Fork 4
Roadmap
Ashutosh Kumar edited this page Mar 10, 2023
·
3 revisions
The items provided below are ordered arbitrarily and pending priority identification.
Legends:
- HP - High Priority
- HE - High Effort
- WIP - Work In Progress
- Applicable for snappi, gosnappi
- Enables logging API requests / response and other information that may be needed for debugging
- Allow users to control the logging options (e.g. level, file, etc.) and integrate seamlessly with logger used in projects using snappi / gosnappi
- Applicable for snappi, gosnappi
- Exercise standard approach for embedding instrumentation code using OTLP
- Enable co-relation of instrumentation data between client and server
- Applicable for snappi, gosnappi
- Track performance regression in generated SDK upon new release
- Maintain CDF plots per release
- Applicable for models, snappi, gosnappi
- Generate type closest to the min-max range provided in models for fields
- Support unsigned integer format in models for fields
- Applicable for models
- Auto-generate tracking window configuration for all fields of all headers
- Applicable for snappi, gosnappi
- Automatic validation of name properties marked with x-unique
- Applicable for snappi, gosnappi
- Automatic validation of name properties marked with x-constraint
- Applicable for models, snappi, gosnappi
- Simplify error API
- Simplify error inspection in SDK
- Applicable for models, snappi, gosnappi
- Mark x-field-uid as optional
- Restore behavior of x-include (requires repurposing x-field-uid)
- Generate structs in Go when gRPC structs are not available
- Applicable for snappi, gosnappi
- Error message needs to be consistent across python and go
- Applicable for gosnappi
- The check is currently disabled because we generate non-pointer type for required fields
- When required field is deprecated, users are still forced to provide values for it until it's actually removed
- Applicable for gosnappi, snappi
- Introduce more utilities for waiting, polling
- Introduce more utilities for printing metrics in tabular format
- Applicable for gosnappi
- Current implementation of iterators introduces a complexity in how wrappers are generated around base structures
- Iterating over items should not require calling a separate method on iterators - it's non intuitive
- Some very commonly used methods need to be part of iterators - e.g. find by name
- Applicable for openapiart
- Today one has to provide these with updated versions of components manually, which is error prone
- Generate SDKs with correct defaults (e.g. package name, path, etc.) - today the location for different artifacts is arbitrarily
- Applicable for openapiart
- Today we accept python script for customization which has flaws when things not provided in specific order
- Applicable for gosnappi
- Ensure two gosnappi objects can be compared using reflection API
- Applicable for snappi, gosnappi
- Needs more exploration, but idea is to, without breaking tests, automatically switch between streaming communication vs req-resp communication based on payload size.
- Applicable for snappi, gosnappi
- Allow serializing / de-serializing of structures without any validation
- Needed for scenarios where repeating the validation on client and server side is undesirable
- Applicable for snappi, gosnappi
- The unit test needs to be auto-generated for positive and negative use cases
- Applicable for snappi
- Incorporate typing for all snappi objects and their properties / methods
- Deprecate support for Python 2.7, since it has poor typing support
- This enables better intellisense in code editors, which is missing today
- Applicable for openapiart
- Check for presence of go, protoc, protoc plugins, etc. and raise error if they're required
- Applicable for snappi, gosnappi
- Use case: MAC address is a required field but it would help if the values are automatically generated
- May need to introduce a new x-extension
- Applicable for snappi, gosnappi
- Implementation should be able to provide a list of schemas, fields, enum values, field values that are currently not supported
- Submission to main branch should always result in automatic pre-release
- Pre release builds should be following
x.y.z-buildconvention - Manual trigger needs to be provided to create release of the form
x.y.z
- A lot of components that may potentially use openapiart-generated SDK are written in C++
- This is important for more wide-spread adaption
- Allow generating snappi and gosnappi code from .YAML or .JSON
- The logic to do so shall reside in SDK itself
- Multiple teams are currently relying on proprietary API or .proto api
- It's feasible to transform these API to equivalent openapiart-compatible API
- openapiart should accept plugin that contains small logic for transforming API
- This will help further adaption of openapiart
- Applicable for snappi, gosnappi
- Need to reconsider whether choice fields should be allowed to be modified multiple times