Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Some ideas for API improvements #1412

Open
Daniel-Abrecht opened this issue Jun 9, 2018 · 2 comments
Open

Some ideas for API improvements #1412

Daniel-Abrecht opened this issue Jun 9, 2018 · 2 comments

Comments

@Daniel-Abrecht
Copy link

@Daniel-Abrecht Daniel-Abrecht commented Jun 9, 2018

While I was working on my magnet-protocolhandler project, I noticed a few things that have been a bit inconvenient:

  1. client.add can only be called once for a torrent

While writing a webapp where a magnet url can be entered, it's quiet tempting to just use client.add, but if the same torrent is entered again, it will fail. After I noticed this, I used client.get first, and than either waited for the torrents ready event if it was already added or use client add otherwise. But then I notices that I can miss the ready event, so I had to check if the torrent was already ready first. I ended up with the following function:

function addOrGetTorrent(uri,callback){
  var torrent = webtorrent.get(uri);
  if(torrent){
    if(torrent.ready){
      callback(torrent);
    }else{
      torrent.on("ready",()=>callback(torrent));
    }
  }else{
    webtorrent.add(uri,callback);
  }
}

Since this seams like a pretty common use case, and it's so easy to get wrong, it would be nice to have something like this as a convenience function, or alternatively a parameter for the add function so it can be used for the same torrent more than once.

  1. There is no way to retrieve a single common webtorrent instance.

Currently, there is only a constructor using which any number of webtorrent instances can be created. If multiple independent libraries use webtorrent, they need to obtain a webtorrent instance, so they may all create a new one. But what would the implications of that be? The instances wouldn't share the added torrents and other things, so could that lead to a lot of resources wasted if multiple libraries add the same torrent, for example?

I think it would be nice to have a singleton function, so that all libraries can use that function to get a single shared webtorrent instance. I'm just not sure what to do about the options that can be passed to the webtorrent constructor in that case though.

Lastly, I would like to thank everyone for creating this truly awesome library.

@feross

This comment has been minimized.

Copy link
Member

@feross feross commented Jun 9, 2018

Thanks for the thoughtful suggestions. I'd like to consider some of these ideas when we release a promise-based API sometime in the future. I think @DiegoRBaquero had interest in working on this at open point.

@stale

This comment has been minimized.

Copy link

@stale stale bot commented Sep 7, 2018

This issue has been automatically marked as stale because it has not had recent activity. It will be closed if no further activity occurs.

@stale stale bot added the stale label Sep 7, 2018
@stale stale bot closed this Sep 14, 2018
@lock lock bot locked as resolved and limited conversation to collaborators Dec 13, 2018
@feross feross added the enhancement label Aug 10, 2019
@feross feross reopened this Aug 10, 2019
@stale stale bot removed the stale label Aug 10, 2019
@feross feross added the area/ux label Aug 10, 2019
@webtorrent webtorrent unlocked this conversation Aug 10, 2019
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Linked pull requests

Successfully merging a pull request may close this issue.

None yet
2 participants
You can’t perform that action at this time.