RestClient subscriptions #48
Conversation
|
In general, the CLI is a good candidate for refactoring/cleaning up. While it works, and the click decorator does seem elegant, it is also a jumble and getting near to spaghetti code (in a way). While this is not pressing now (probably the last thing we do), we should start thinking about this. |
| currencies = cls._validate_parameter('currencies', currencies) | ||
| channels = cls._validate_parameter('channels', channels) | ||
| def subscribe(self, assets, currencies, channels, exchange=None, | ||
| interval=1.0): |
There was a problem hiding this comment.
Is interval in seconds? If so, perhaps we can call it interval_seconds
| handlers=self._get_handlers(), | ||
| ) | ||
| # FIXME: find a better way to do this | ||
| subscription.listener = self._listener(subscription, interval=interval, |
There was a problem hiding this comment.
Can you ping me on WA and detail ideas about what is a better way to do this?
There was a problem hiding this comment.
I'm not sure. I think it will come out in the wash once we think carefully about how to share the sockets across subscriptions.
| def _get_handlers(cls): | ||
| return [getattr(cls, attr) for attr in dir(cls) | ||
| if callable(getattr(cls, attr)) | ||
| and attr.startswith('parse_')] |
There was a problem hiding this comment.
The node community uses the prefix on. So for example, on_connect and on_trade. It seems like it is a very short prefix and quite descriptive of the purpose. What do you think?
There was a problem hiding this comment.
So some of the python websocket client classes do this too. I see the point. If we go with the event handler publishing straight to the stream model then I think that sounds like a good convention, i.e. for the Websocket subscription handle_*() handlers. These ones just parse a message and return an event so slightly less appropriate here in my opinion but let me think about it for a bit and get back to you.
Adds ability to subscribe to RestClient updates (currently prices and tickers)