Conversation
|
Some things from talking to claude (maybe you find it useful):
|
| async def __anext__(self) -> DataTrackFrame: | ||
| if self._closed: | ||
| raise StopAsyncIteration | ||
|
|
||
| event: proto_ffi.FfiEvent = await self._queue.get() |
There was a problem hiding this comment.
question: Should the python implementation of data tracks be updated to have the synchronous track.subscribe() behavior which was implemented in javascript, with any subscription errors cascading down into the first iterator __anext__ call?
There was a problem hiding this comment.
Discussed on slack with @ladvoc, we decided this behavior makes sense to do here as well!
| class PublishDataTrackError(Exception): | ||
| def __init__(self, message: str) -> None: | ||
| self.message = message |
There was a problem hiding this comment.
question: Is it worth exposing a more rich set of errors here instead of just the single error with the message, like rust / js have added?
| """Subscribes to the data track to receive frames. | ||
|
|
||
| Args: | ||
| buffer_size: Maximum number of received frames to buffer internally. |
There was a problem hiding this comment.
thought: I realize this could get out of date quickly if the default starts changing a bunch, but it might be nice to actually include the default value here (I think it is 16?).
Or maybe another alternative to sidestep that duplication concern could be to link to the future docs page (probably will be https://docs.livekit.io/transport/data/data-tracks/#buffer-size) where this is mentioned.
No description provided.