On Tue, Jan 8, 2013 at 10:22 PM, Andrew Grieve <[email protected]> wrote:
> Rather than "binary data", I think we should focus strictly on > "ArrayBuffer". I think the only other binary data concept is Blob, and Blob > is easy to create from an ArrayBuffer. > > As for how to have one of these show up in a JSON object, I think it will > be tough to make this work. Most platforms assume that you can paste the > JSON into an eval / JSON.parse, and it will come out correctly. That can't > be the case for ArrayBuffers. Maybe we should just not support this. The > use-case here is being able to pass multiple values to callbacks. For > ArrayBuffers, maybe we can passing the usual payload plus an optional > ArrayBuffer as an additional parameter. I don't think it would be necessary > to have multiple ArrayBuffers for a single callback... > To understand correct, does this mean that you propose a single ArrayBuffer instead of an arguments list, or, to add a 6th parameter to exec which is the one and only ArrayBuffer? I propose yet another option, maybe you can any number of ArrayBuffers in the arguments list, but not embedded in any subobject. Thus, semantically the arguments array stops being JSON serializable, and the individual arguments are either ArrayBuffers or json-serializable (this also leaves door open to add more types in the future). > > > My ideas for transferring this over the bridge on iOS include: - an array of numbers > - a string of shorts encoded as chars with unicode chars encoded as \uXXXX > - a URL that the client can fetch via XHR and we can return the binary data > via CDVURLProtocol (advantage here is that XHR2 can request the payload as > an ArrayBuffer instead of having to construct the ArrayBuffer > after-the-fact > interesting idea! > > For Android, the string of short-encoded chars is probably the best bet > since the bridge natively supports transferring strings without having to > parse them as JS literals. > > > > On Tue, Jan 8, 2013 at 4:05 PM, Michal Mocny <[email protected]> wrote: > > > Created https://issues.apache.org/jira/browse/CB-2173 > > > > > > On Tue, Jan 8, 2013 at 3:52 PM, Michal Mocny <[email protected]> wrote: > > > > > Background: I've been working on implementing chrome.socket [1] for > > mobile > > > chrome apps [2] and porting circ (an irc chrome app) [3]. Teaser > video: > > > https://docs.google.com/open?id=0B0UdPHoQPXheTzhTZXZHUlpGWHM (this is > > > still in its infancy, and I certainly do plan to submit a version of > the > > > socket api that will work in cordova without any mobile chrome app > > magic). > > > > > > As part of doing that, I had to implement sending binary data across > the > > > exec bridge (on ios for now), and I think it may be a good idea to just > > add > > > that functionality to cordova core. My current implementation is > > certainly > > > not the best, so I will extend the exec bridge echo benchmarks to test > > > binary transfer speeds and we can improve over time. > > > > > > My first step would be to implement helpers in js/ios/android which > > plugin > > > devs can call manually to serialize/deserialize binary data into/from > > > whatever magical form is most efficient. > > > > > > Next, I would try to automate these helpers from within the exec call > > > (e.g. iterate arguments looking for ArrayBuffer/Blob/etc types before > > json > > > serialization). As part of doing this, I would need to add "hints" > about > > > the underlying argument types/some clever way to encode semantic > > > information about the arguments list, which we currently do not do. > > > > > > If anyone has any suggestions or objections please let me know! > > > > > > -Michal > > > > > > [1] http://developer.chrome.com/apps/socket.html > > > [2] > > > > > > https://github.com/MobileChromeApps/chrome-cordova/blob/master/api/chrome/socket.jsand > > > https://github.com/MobileChromeApps/chrome-cordova/tree/master/plugins > > > [3] https://github.com/flackr/circ > > > > > >
