abstract filesystem calls
KJLJon opened this issue · 2 comments
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.
namespace starekrow\lockbox;
interface FileSystemInterface {
/**
* gets the content of a file
* @param string $file
* @return string
*/
public function get($file);
/**
* puts content into a file
* @param string $file
* @param string $content
* @return bool if it was successful
*/
public function put($file, $content);
/**
* checks if the file exists
* @param string $file
* @return bool if it exists
*/
public function has($file);
}
namespace starekrow\lockbox;
class LocalFileSystem implements FileSystemInterface {
/**
* @inheritdoc
*/
public function get($file)
{
return @file_get_contents($file);
}
/**
* @inheritdoc
*/
public function put($file, $content)
{
return @file_put_contents($file, $content);
}
/**
* @inheritdoc
*/
public function has($file)
{
return file_exists($file);
}
}
Interesting; I’d be happy to see a PR along these lines. FYI, the main considerations that went into the design of the CryptoCore:
- Semantic ease of use: Being able to call Crypto::hash(...) without any preliminaries is important.
- see point 1.
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).