On Wed, Jan 9, 2013 at 10:15 AM, Michal Mocny <[email protected]> wrote:
> 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). > Hmm, I wasn't even thinking about the JS->native case actually. I was only thinking about native->JS. What you propose sounds good for JS->Native. > > > > > > > > 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 > > > > > > > > > >
