You signed in with another tab or window. Reload to refresh your session.You signed out in another tab or window. Reload to refresh your session.You switched accounts on another tab or window. Reload to refresh your session.Dismiss alert
vfs is not consistent on how configuration is is passed. We created the vfs.Options empty interface type but don't explicitly require how to use it and always end up just casting it as the version-specific variant. Some backends don't need configuration at all. Others accept env vars are use a set of chain-able function like WithOptions or WithClient.
Though NewFileSystem isn't enforceable, we should use the functional options system that i've used for various functions like Delete and NewFile.
The Retry function in the vfs.FileSystem interface was instituted as a common way to use a retry wrapper. However, it's only ever been implemented to the gs backend. Other backends have their own internal retry functionality while other have none but either way, Retry in those cases always returns a no-op retrier and is never even called internally. Also it has little to no value externally. Retrier configuration could just as easily be passed either within a backend option or as its own type via the NewFileSystem functional option.
Proposed
create a function option interface for NewFileSystem
implement backend-specific functional options to replace chain-able functions
deprecate vfs.Options
deprecate vfs.Retry and related types
The text was updated successfully, but these errors were encountered:
* add deprecations in interface, add functional option. Fixes#238
* update s3 backend to deprecate vfs.Retry and vfs.Options and add newfilesystem functional options
* update azure backend to deprecate vfs.Retry and vfs.Options and add newfilesystem functional options
* update ftp backend to deprecate vfs.Retry and vfs.Options and add newfilesystem functional options
* update sftp backend to deprecate vfs.Retry and vfs.Options and add newfilesystem functional options
* update mem backend to deprecate vfs.Retry and vfs.Options and add newfilesystem functional options
* update os backend to deprecate vfs.Retry and vfs.Options and add newfilesystem functional options
* update gs backend to deprecate vfs.Retry and vfs.Options and add newfilesystem functional options
* add changelog entry
* update dependencies
* revert to storage/v1.51.0
* update doc
* add generics to simplify apply opts
* removed gs use of vfs.Retry
* updated documentation and changelog
* add comments to public functions
* fix whitespace
* updated readme
* removed redundant links in readme
vfs
is not consistent on how configuration is is passed. We created thevfs.Options
empty interface type but don't explicitly require how to use it and always end up just casting it as the version-specific variant. Some backends don't need configuration at all. Others accept env vars are use a set of chain-able function likeWithOptions
orWithClient
.Though
NewFileSystem
isn't enforceable, we should use the functional options system that i've used for various functions like Delete and NewFile.The
Retry
function in thevfs.FileSystem
interface was instituted as a common way to use a retry wrapper. However, it's only ever been implemented to thegs
backend. Other backends have their own internal retry functionality while other have none but either way, Retry in those cases always returns a no-op retrier and is never even called internally. Also it has little to no value externally. Retrier configuration could just as easily be passed either within a backend option or as its own type via theNewFileSystem
functional option.Proposed
The text was updated successfully, but these errors were encountered: