xanderbailey opened a new issue, #2036:
URL: https://github.com/apache/iceberg-rust/issues/2036
### Is your feature request related to a problem or challenge?
## Idiomatic Rust Design for `InputFile` with Encryption Support
While researching the encryption project, I've noticed we need to make some
design decisions where we can't exactly follow the current Java implementation
and need to make things more idiomatic for Rust.
One key example is `InputFile`. In Java, this is an interface that allows
for implementations like `NativeEncryptionInputFile`. In Rust, the idiomatic
way to represent this polymorphism is through an enum rather than trait objects.
### Proposed Design
I have a rough draft that refactors `InputFile` from a single struct to an
enum with variants:
```rust
/// A file input, either encrypted or unencrypted.
pub enum InputFile {
/// Encrypted file input
NativeEncryption(NativeEncryptedInputFile),
/// Unencrypted file input
Unencrypted(UnencryptedInputFile),
}
/// Unencrypted file input
#[derive(Debug)]
pub struct UnencryptedInputFile {
op: Operator,
path: String,
relative_path_pos: usize,
}
/// Encrypted file input
#[derive(Debug)]
pub struct NativeEncryptedInputFile {
op: Operator,
path: String,
relative_path_pos: usize,
// Add encryption-specific fields here, e.g.:
// key: EncryptionKey,
}
```
The public API methods delegate to the appropriate variant:
```rust
impl InputFile {
pub fn location(&self) -> &str {
match self {
InputFile::NativeEncryption(f) => f.location(),
InputFile::Unencrypted(f) => f.location(),
}
}
pub async fn read(&self) -> crate::Result<Bytes> {
match self {
InputFile::NativeEncryption(f) => f.read().await,
InputFile::Unencrypted(f) => f.read().await,
}
}
// ... other methods follow the same pattern
}
```
### Benefits
1. **Zero-cost abstraction** - No vtable overhead like with `dyn` trait
objects
2. **Exhaustive pattern matching** - Compiler ensures all variants are
handled
3. **Clear type representation** - Encryption state is encoded in the type
system
4. **Easy to extend** - Adding new variants (e.g., `Compressed`?) is
straightforward
### Trade-offs
This is actually a relatively small code change but provides a foundation
for extending `InputFile` capabilities while maintaining Rust idioms. The main
consideration is that this approach is more explicit than Java's
interface-based design, but that explicitness is generally considered a
strength in Rust.
### Related Work
This pattern is similar to how we might handle readers, where we also need
an enum wrapper to avoid `Box<dyn FileReader>`:
```rust
pub enum InputFileReader {
Encrypted(opendal::Reader),
Unencrypted(opendal::Reader),
}
```
Would appreciate feedback on this approach before proceeding with full
implementation.
### Describe the solution you'd like
_No response_
### Willingness to contribute
None
--
This is an automated message from the Apache Git Service.
To respond to the message, please log on to GitHub and use the
URL above to go to the specific comment.
To unsubscribe, e-mail: [email protected]
For queries about this service, please contact Infrastructure at:
[email protected]
---------------------------------------------------------------------
To unsubscribe, e-mail: [email protected]
For additional commands, e-mail: [email protected]
