Hi I recently published olio (crate), a crate with some new and some overlapping utilities. As described in the rust forum announcement, I found positioned-io but couldn't quite make it work for my use cases. In particular:
(a) The positioned_io::Slice appears to require owning its ReadAt implementation on construction, in my case a File. In one use case, I need to have multiple Read-supporting slice-like instances over a shared file. This is why I have the current olio::fs::rc::ReadSlice take a Arc<File> reference.
(b) I have a container format that I want to exclusively control writes to, but expose a Read-only Slice in my reading API. In olio, I currently only support reads for these types, but positioned_io is much more complete with its write-support.
For (a), in dekellum/olio#1 I've prototyped making my ReadSlice generic over Borrow<File> which makes it compatible with owned File, &File, Arc<File>, etc. I haven't tried it yet, but would you consider a PR to make that kind of change here? This would probably be a breaking change in a strict rust-sense, but as in my PR, type aliases might make it only require a recompile in all or most cases.
For (b) it would seem pretty easy to keep the existing Read/Write Slice type but add a secondary ReadSlice which only exposes the Read-side of the interface.
I realize this a pretty broad request—how lively is positioned-io as a project and is there much interest in some significant contributions/changes of this nature? I commented on #1 because this is the kind of thing I'd expect to see completed and merged. I'd also want to fix some clippy lints, modernize some rust features like ? replacing try!, and maybe add some benchmarks to "merge" and contribute my olio work.
Thanks for your work on positioned-io, either way!
Hi I recently published olio (crate), a crate with some new and some overlapping utilities. As described in the rust forum announcement, I found positioned-io but couldn't quite make it work for my use cases. In particular:
(a) The
positioned_io::Slice
appears to require owning itsReadAt
implementation on construction, in my case aFile
. In one use case, I need to have multipleRead
-supporting slice-like instances over a shared file. This is why I have the currentolio::fs::rc::ReadSlice
take aArc<File>
reference.(b) I have a container format that I want to exclusively control writes to, but expose a
Read
-only Slice in my reading API. In olio, I currently only support reads for these types, butpositioned_io
is much more complete with its write-support.For (a), in dekellum/olio#1 I've prototyped making my
ReadSlice
generic overBorrow<File>
which makes it compatible with ownedFile
,&File
,Arc<File>
, etc. I haven't tried it yet, but would you consider a PR to make that kind of change here? This would probably be a breaking change in a strict rust-sense, but as in my PR, type aliases might make it only require a recompile in all or most cases.For (b) it would seem pretty easy to keep the existing Read/Write
Slice
type but add a secondaryReadSlice
which only exposes theRead
-side of the interface.I realize this a pretty broad request—how lively is positioned-io as a project and is there much interest in some significant contributions/changes of this nature? I commented on #1 because this is the kind of thing I'd expect to see completed and merged. I'd also want to fix some clippy lints, modernize some rust features like
?
replacingtry!
, and maybe add some benchmarks to "merge" and contribute my olio work.Thanks for your work on
positioned-io
, either way!