Simplified node creation #343
Conversation
Signed-off-by: ljedrz <ljedrz@gmail.com>
Signed-off-by: ljedrz <ljedrz@gmail.com>
Signed-off-by: ljedrz <ljedrz@gmail.com>
Signed-off-by: ljedrz <ljedrz@gmail.com>
| } | ||
|
|
||
| /// Initialize the ipfs node. The returned `Ipfs` value is cloneable, send and sync, and the | ||
| /// future should be spawned on a executor as soon as possible. | ||
| pub async fn start(self) -> Result<(Ipfs<Types>, impl Future<Output = ()>), Error> { | ||
| pub async fn start(&mut self) -> Result<impl Future<Output = ()>, Error> { |
There was a problem hiding this comment.
The story behind of UninitializedIpfs was probably to originally work around some Send or Sync bounds related to some type which is no longer an issue however I think the real benefit of UninitalizedIpfs was that there was no start on Ipfs which would be called multiple times as the move semantics of the lang give rise to nicer APIs.
What does one do with an Ipfs value if the start fails?
Could the start be moved to IpfsOptions...? As a build method or something? Or maybe in place of new?
There was a problem hiding this comment.
What does one do with an Ipfs value if the start fails?
same applies to UninitializedIpfs, no? I'm all for improving the naming here, I'll think about it
There was a problem hiding this comment.
Well UninitializedIpfs is a worthless value in itself except for starting, and start consumed itself, so you don't have a value left.
There was a problem hiding this comment.
while working on ipfs-substrate I had a case where it was easy to spawn tasks, but you had no control over what they were returning, making the setup practical for long-running tasks, but not for instantiating stuff like here; with this change the benefit is that Ipfs can be created (and kept) in a non-async context, while the background task can be consumed/concealed away; actually, since Ipfs is Clone, this can still consume self (and additionally return Ipfs), would that be better?
Signed-off-by: ljedrz <ljedrz@gmail.com>
|
Obviated by #345. |
... instead of Ipfs. this was the original idea in rs-ipfs#343 perhaps.
The
UninitializedIpfsstruct neither has to be created usingasyncnor is it necessary as a proxy object at all. We can simplify things even further, by not having the proxyIpfsInnerobject either.This is a draft to "gauge the room" - if this is indeed a preferable course of action, I'll fix the docs, tests etc.