Open fernand0 opened 1 year ago
Hello @fernand0 I've never thought of using it like this, but since the TwitterCall class's domain attribute is accessible and is reread at every API call, I don't see why your proposition wouldn't be a valid solution. You can propose a PR for the documentation if you like. Regarding doing this internally, this would mean hardcoding attachment of some api routes to some specific domains which is hard to maintain in the long run as new routes keep appearing, but I see the interest of having it for this quite specific and annoying case. In which case we should just ensure that the user can force the domain of his choice in any case and not let the magic block other wishes. I'll be happy to review a PR for this.
I've been testing media uploading following the examples provided in the README. The method is based on creating a new instance of the Twitter class:
And later using the old instance to add the uploaded media to a tweet:
I've been testing a different approach, that could be like:
Changing the domain in the instance of the Twitter class:
t.domain = 'upload.twitter.com'
Uploading the images with the original instance of the Twitter class (but with different domain).
Changing the domain to the original one:
t.domain = 'api.twitter.com'
Publishing the tweet containing the images.
I was wondering if this approach is ok (and, I believe, more simple than creating a secondary instance to upload images). If this is true, maybe it would be nice to modify de upload methods to change internally the domain and so on. Or, at least, maybe providing the adequate methods for changing the domains when needed.