{"action":"created","issue":{"url":"https://api.github.com/repos/facebook/react-native/issues/6327","repository_url":"https://api.github.com/repos/facebook/react-native","labels_url":"https://api.github.com/repos/facebook/react-native/issues/6327/labels{/name}","comments_url":"https://api.github.com/repos/facebook/react-native/issues/6327/comments","events_url":"https://api.github.com/repos/facebook/react-native/issues/6327/events","html_url":"https://github.com/facebook/react-native/pull/6327","id":138855558,"number":6327,"title":"Add support for sending binary data in websockets.","user":{"login":"jeremyong","id":250149,"avatar_url":"https://avatars.githubusercontent.com/u/250149?v=3","gravatar_id":"","url":"https://api.github.com/users/jeremyong","html_url":"https://github.com/jeremyong","followers_url":"https://api.github.com/users/jeremyong/followers","following_url":"https://api.github.com/users/jeremyong/following{/other_user}","gists_url":"https://api.github.com/users/jeremyong/gists{/gist_id}","starred_url":"https://api.github.com/users/jeremyong/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/jeremyong/subscriptions","organizations_url":"https://api.github.com/users/jeremyong/orgs","repos_url":"https://api.github.com/users/jeremyong/repos","events_url":"https://api.github.com/users/jeremyong/events{/privacy}","received_events_url":"https://api.github.com/users/jeremyong/received_events","type":"User","site_admin":false},"labels":[{"url":"https://api.github.com/repos/facebook/react-native/labels/CLA%20Signed","name":"CLA Signed","color":"e7e7e7"},{"url":"https://api.github.com/repos/facebook/react-native/labels/GH%20Review:%20review-needed","name":"GH Review: review-needed","color":"fbca04"}],"state":"closed","locked":false,"assignee":null,"milestone":null,"comments":9,"created_at":"2016-03-07T00:44:49Z","updated_at":"2016-03-07T09:01:19Z","closed_at":"2016-03-07T06:24:07Z","pull_request":{"url":"https://api.github.com/repos/facebook/react-native/pulls/6327","html_url":"https://github.com/facebook/react-native/pull/6327","diff_url":"https://github.com/facebook/react-native/pull/6327.diff","patch_url":"https://github.com/facebook/react-native/pull/6327.patch"},"body":"This is a resubmission of #6190 which addresses the odd merge conflicts and is completely up-to-date with master. It was tested locally in house, but if there are suggestions about how to expand the test suite I'm all ears."},"comment":{"url":"https://api.github.com/repos/facebook/react-native/issues/comments/193165468","html_url":"https://github.com/facebook/react-native/pull/6327#issuecomment-193165468","issue_url":"https://api.github.com/repos/facebook/react-native/issues/6327","id":193165468,"user":{"login":"satya164","id":1174278,"avatar_url":"https://avatars.githubusercontent.com/u/1174278?v=3","gravatar_id":"","url":"https://api.github.com/users/satya164","html_url":"https://github.com/satya164","followers_url":"https://api.github.com/users/satya164/followers","following_url":"https://api.github.com/users/satya164/following{/other_user}","gists_url":"https://api.github.com/users/satya164/gists{/gist_id}","starred_url":"https://api.github.com/users/satya164/starred{/owner}{/repo}","subscriptions_url":"https://api.github.com/users/satya164/subscriptions","organizations_url":"https://api.github.com/users/satya164/orgs","repos_url":"https://api.github.com/users/satya164/repos","events_url":"https://api.github.com/users/satya164/events{/privacy}","received_events_url":"https://api.github.com/users/satya164/received_events","type":"User","site_admin":false},"created_at":"2016-03-07T09:01:18Z","updated_at":"2016-03-07T09:01:18Z","body":"@jeremyong\r\n\r\n> I'm not sure I agree with the conclusion. The bridge marshalls data over as JSON right? I don't see how this can be done without a heavy overhaul of the bridge.\r\n\r\nI think the bridge needs to support streaming data, or have a new way of streaming data. For which we don't have a solution yet.\r\n\r\n> In the meantime, websocket only handles TEXT which is being copied over regardless! Whether it's binary or text makes no difference but because RN does not support binary, developers are forced to base64 encode binary and send it over the network which is far worse than an in memory copy.\r\n\r\nThere's a big difference between text and binary files. Binary files are mostly significantly larger than text files. base64 encoding it means even larger size.\r\n\r\n> With respect to ArrayBuffers, creating a different overload for interpreting a string as binary works easily enough. But as it stands, I believe the current WS code/bridge to be completely unusable. There is an entire frame opcode type that is unavailable for use, and I would prefer full functionality with well documented caveats over no functionality at all. The workarounds in this case are strictly worse.\r\n\r\nIf you can provide a sane fallback for iOS 7 with ArrayBuffer for new versions, that's acceptable too.\r\n\r\n> My final question I suppose is, if you have an performance problem with how this is working, why isn't literally everything else that gets marshalled back and forth across the RN bridge a problem too?\r\n\r\nEverything which goes across the bridge is very small amount of data. So its not a problem. It's a problem if you try sending a 5MB of data across the bridge. The bridge is not designed for that. And I'm afraid I don't have a solution for this yet.\r\n\r\n> Another question, if the stipulation is that you don't want to copy across the bridge, do you at least have another suggestion for going about this? If a copy isn't made, than the implementer needs to make some guarantee that the JS execution thread won't attempt to modify the memory. What mechanism can be used to prevent this?\r\n\r\nOne thing I can think of is to have a proprietary extension to WebSocket like we do in XMLHttpRequest. For example, we allow sending a file through ajax by specifying a file URI on JS side. The native side handles reading the file and sending it to remote.\r\n\r\ncc @dmmiller @mkonicek @nicklockwood \r\n\r\n> I totally agree with @jeremyong. I would prefer a working solution that might not be the most efficient one over a solution that do not work at all. Is there another way of solving this issue?\r\n\r\nIt's not just 'might not be the most efficient', it's not at all efficient. If we add this, people will start abusing it."}}