pub trait WalletStorage {
fn get(&self, type_: &[u8], id: &[u8], options: &str) -> Result<StorageRecord, IndyError>;
fn add(&self, type_: &[u8], id: &[u8], value: &EncryptedValue, tags: &[Tag]) -> Result<(), IndyError>;
fn update(&self, type_: &[u8], id: &[u8], value: &EncryptedValue) -> Result<(), IndyError>;
fn add_tags(&self, type_: &[u8], id: &[u8], tags: &[Tag]) -> Result<(), IndyError>;
fn update_tags(&self, type_: &[u8], id: &[u8], tags: &[Tag]) -> Result<(), IndyError>;
fn delete_tags(&self, type_: &[u8], id: &[u8], tag_names: &[TagName]) -> Result<(), IndyError>;
fn delete(&self, type_: &[u8], id: &[u8]) -> Result<(), IndyError>;
fn get_storage_metadata(&self) -> Result<Vec<u8>, IndyError>;
fn set_storage_metadata(&self, metadata: &[u8]) -> Result<(), IndyError>;
fn get_all(&self) -> Result<Box<dyn StorageIterator>, IndyError>;
fn search(&self, type_: &[u8], query: &language::Operator, options: Option<&str>) -> Result<Box<dyn StorageIterator>, IndyError>;
fn close(&mut self) -> Result<(), IndyError>;
}
The API calls are all blocking - consequently many other APIs are blocking, for example create_and_store_my_did. It's quite easy to overlook when using IndySDK with the default local sqlite wallet implementation as it's quite fast. It becomes more of an issue when storage IO is slower. I am using pgsql plugin, and read operation such as WalletStorage::get takes 4ms - so for that duration, my thread is blocked. In create_and_store_my_did there's 1 read and 3 writes and so that can easily block my thread due to IO for 20ms (well, I can add few more threads to IndySDK executor, but they easily can get stuck on IO while they could had been doing some actual work instead).
I understand that the API was written quite a while ago and at the time, Rust futures were probably not yet flashed out much. I also know migrating this to async futures will be huge amount of work. But this seems as important next step to make applications built on IndySDK scalable. So I am writing this issue - gotta start somewhere right? I wonder what's other people thoughts on this.
The wallet API is currently defined as follows:
The API calls are all blocking - consequently many other APIs are blocking, for example
create_and_store_my_did. It's quite easy to overlook when using IndySDK with the default local sqlite wallet implementation as it's quite fast. It becomes more of an issue when storage IO is slower. I am using pgsql plugin, and read operation such asWalletStorage::gettakes 4ms - so for that duration, my thread is blocked. Increate_and_store_my_didthere's 1 read and 3 writes and so that can easily block my thread due to IO for 20ms (well, I can add few more threads to IndySDK executor, but they easily can get stuck on IO while they could had been doing some actual work instead).I understand that the API was written quite a while ago and at the time, Rust futures were probably not yet flashed out much. I also know migrating this to async futures will be huge amount of work. But this seems as important next step to make applications built on IndySDK scalable. So I am writing this issue - gotta start somewhere right? I wonder what's other people thoughts on this.