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
The current api does not support multiple uploads so one would have to make multiple Constellation::put calls and poll each stream that is returned to completion. While one could get around this by polling the streams, either individually or collectively (since the progress does return a name that can be tracked), I do believe it might be more optimal to support an api that would do this internally while the end user would only have one stream to poll.
Note:
There may be a limit to how many can be uploaded at one given time in warp-ipfs. While this "upload" is nothing more than storing it on the local node, we do not want to have a overwhelming number of files being stored at one given time, especially if a protocol is introduced to broadcast blocks or files out, or if the system storage is not the best. While we could batch these into separate task once it reach a threshold, I do feel that may not be desirable long term. Furthermore, when it comes to pinning these files on shuttle or some other service (if any), we dont want to have a overwhelming amount of data that may take a long time to pin either.
The text was updated successfully, but these errors were encountered:
The current api does not support multiple uploads so one would have to make multiple
Constellation::put
calls and poll each stream that is returned to completion. While one could get around this by polling the streams, either individually or collectively (since the progress does return a name that can be tracked), I do believe it might be more optimal to support an api that would do this internally while the end user would only have one stream to poll.Note:
The text was updated successfully, but these errors were encountered: