The current API for creating a Builder, Network, and Parser is very similar to the C++ API provided by TensorRT. This isn't exactly a bad thing but using it in practice feels like there are a lot of steps to construct that could be slimmed down. We should take a little time to look at different possibilities for APIs that can be provided by the crate that are a little better than 1 to 1 mappings of the C++ APIs.
I'm not against keeping the types around as is since they provided flexibility when building networks in situations that aren't exactly the same as our use cases. Maybe the answer is that it's better to build the abstraction in the application itself out of the types that the crate provides rather than tying to force a use case specific API into a more general context.
The current API for creating a Builder, Network, and Parser is very similar to the C++ API provided by TensorRT. This isn't exactly a bad thing but using it in practice feels like there are a lot of steps to construct that could be slimmed down. We should take a little time to look at different possibilities for APIs that can be provided by the crate that are a little better than 1 to 1 mappings of the C++ APIs.
I'm not against keeping the types around as is since they provided flexibility when building networks in situations that aren't exactly the same as our use cases. Maybe the answer is that it's better to build the abstraction in the application itself out of the types that the crate provides rather than tying to force a use case specific API into a more general context.