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
I think the file system calls in Vault should be abstracted into an interface so the vault could be stored in other locations and someone could leverage packages like flysystem.
Of course default it with the file system for ease of use.
namespacestarekrow\lockbox;
interface FileSystemInterface {
/** * gets the content of a file * @param string $file * @return string */publicfunctionget($file);
/** * puts content into a file * @param string $file * @param string $content * @return bool if it was successful */publicfunctionput($file, $content);
/** * checks if the file exists * @param string $file * @return bool if it exists */publicfunctionhas($file);
}
Upon reflection, feel free to ignore that comment. It made a lot of sense for Crypto to be set up as an accessible, independent component that was self-configuring. OTOH, the FileSystemInterface could easily be managed by and/or through the Vault class, so adding a bit of required boilerplate to use it is really a non-issue.
I assume you were thinking along the lines of adding a $filesys argument to the Vault constructor that, if left null, would default to LocalFileSystem (or perhaps inspect the given path for "http:" etc).
I think the file system calls in Vault should be abstracted into an interface so the vault could be stored in other locations and someone could leverage packages like flysystem.
Of course default it with the file system for ease of use.
The text was updated successfully, but these errors were encountered: