Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (athena.apache.org: domain of agrieve@google.com designates
 209.85.214.178 as permitted sender)
MIME-Version: 1.0
Sender: agrieve@google.com
In-Reply-To: 
 <CAEeF2TeF54pZq8nCRsKBF8EYvyX0vauiqio70DPpQb8Awd4W2A@mail.gmail.com>
References: 
 <CAEeF2TdoTZ3Haqy=fsYacYV3i1HEQ8vAb_JkTzqgFy6FmHVFsg@mail.gmail.com>
 <CAEeF2TeF54pZq8nCRsKBF8EYvyX0vauiqio70DPpQb8Awd4W2A@mail.gmail.com>
From: Andrew Grieve <agrieve@chromium.org>
Date: Tue, 8 Jan 2013 22:22:46 -0500
Message-ID: 
 <CABiQX1WjWdS7sVw81bAe6Vjf2E8Zf3SkeVT-_fSq_609G09bqQ@mail.gmail.com>
Subject: Re: Binary data across exec bridge
To: dev <dev@cordova.apache.org>
Content-Type: multipart/alternative; boundary=bcaec54d3ef0b53cba04d2d294b0

--bcaec54d3ef0b53cba04d2d294b0
Content-Type: text/plain; charset=ISO-8859-1

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...


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

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 <mmocny@google.com> wrote:

> Created https://issues.apache.org/jira/browse/CB-2173
>
>
> On Tue, Jan 8, 2013 at 3:52 PM, Michal Mocny <mmocny@google.com> 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
> >
>

--bcaec54d3ef0b53cba04d2d294b0--