Mailing-List: contact dev-help@cordova.apache.org; run by ezmlm
Precedence: bulk
Reply-To: dev@cordova.apache.org
Received-SPF: pass (nike.apache.org: domain of mmocny@google.com designates
 209.85.220.49 as permitted sender)
MIME-Version: 1.0
Sender: mmocny@google.com
In-Reply-To: 
 <CAM2q_Uwyqp_tr9vq-1iK0rbSy_8ov2V6EuzgwJTg1XRL6Jb+Xg@mail.gmail.com>
References: 
 <CAEeF2TdoTZ3Haqy=fsYacYV3i1HEQ8vAb_JkTzqgFy6FmHVFsg@mail.gmail.com>
	<CAEeF2TeF54pZq8nCRsKBF8EYvyX0vauiqio70DPpQb8Awd4W2A@mail.gmail.com>
	<CABiQX1WjWdS7sVw81bAe6Vjf2E8Zf3SkeVT-_fSq_609G09bqQ@mail.gmail.com>
	<CAEeF2TdB4Sat8m9HeKXqvf12GUVX54Bun8Vow3i25XbKt81w8w@mail.gmail.com>
	<CABiQX1V9NTGErzhkRpbdLg1Xsi6OGG2G0mafc_4=Oz_pTjY+eQ@mail.gmail.com>
	<CAM2q_Uwyqp_tr9vq-1iK0rbSy_8ov2V6EuzgwJTg1XRL6Jb+Xg@mail.gmail.com>
Date: Tue, 15 Jan 2013 10:28:09 -0500
Message-ID: 
 <CAEeF2TfnBKg9wOsE6K7vG7iQqMLEzUkn-0awT1Dh95hhQw4wTQ@mail.gmail.com>
Subject: Re: Binary data across exec bridge
From: Michal Mocny <mmocny@chromium.org>
To: dev@cordova.apache.org
Content-Type: multipart/alternative; boundary=047d7b10cbcbbc308904d3556884

--047d7b10cbcbbc308904d3556884
Content-Type: text/plain; charset=ISO-8859-1
Content-Transfer-Encoding: quoted-printable

Don, I had previously tried a byte array and found it quite a bit less
efficient.  I'll add that implementation and benchmark it officially.

I did benchmarks on iphone5 today for two initial implementations:
(1) Using base64 encoded javascript strings
(2) Using non base64 encoded, unicode javascript strings

(1) YES BASE64 ENCODE

2013-01-15 10:16:02.233 MobileSpecTest[1930:907] Multi-tasking -> Device:
YES, App: YES
2013-01-15 10:16:02.749 MobileSpecTest[1930:907] [LOG] Device =3D iOS 6.0.2
2013-01-15 10:16:38.104 MobileSpecTest[1930:907] [LOG] Started exec
benchmark with payload length: 1
2013-01-15 10:16:39.103 MobileSpecTest[1930:907] [LOG] Calls per second:
274.72527472527474
2013-01-15 10:16:55.995 MobileSpecTest[1930:907] [LOG] Started exec
benchmark with payload length: 32000
2013-01-15 10:17:01.007 MobileSpecTest[1930:907] [LOG] Calls per second:
18.909235668789808
2013-01-15 10:17:02.795 MobileSpecTest[1930:907] [LOG] Started exec
benchmark with payload length: 32000
2013-01-15 10:17:07.785 MobileSpecTest[1930:907] [LOG] Calls per second:
18.59628074385123
2013-01-15 10:17:14.402 MobileSpecTest[1930:907] [LOG] Started exec
benchmark with payload length: 32
2013-01-15 10:17:19.402 MobileSpecTest[1930:907] [LOG] Calls per second:
265.89364254298283
2013-01-15 10:17:20.651 MobileSpecTest[1930:907] [LOG] Started exec
benchmark with payload length: 32
2013-01-15 10:17:25.651 MobileSpecTest[1930:907] [LOG] Calls per second:
263.69452219112355
2013-01-15 10:17:36.187 MobileSpecTest[1930:907] [LOG] Started exec
benchmark with payload length: 1024
2013-01-15 10:17:41.189 MobileSpecTest[1930:907] [LOG] Calls per second:
185.8141858141858
2013-01-15 10:17:44.701 MobileSpecTest[1930:907] [LOG] Started exec
benchmark with payload length: 1024
2013-01-15 10:17:49.699 MobileSpecTest[1930:907] [LOG] Calls per second:
186.9626074785043
2013-01-15 10:17:51.084 MobileSpecTest[1930:907] [LOG] Started exec
benchmark with payload length: 1024
2013-01-15 10:17:56.082 MobileSpecTest[1930:907] [LOG] Calls per second:
184.8

(2) NO BASE64 ENCODE

2013-01-15 10:12:12.387 MobileSpecTest[1905:907] Multi-tasking -> Device:
YES, App: YES
2013-01-15 10:12:12.892 MobileSpecTest[1905:907] [LOG] Device =3D iOS 6.0.2
2013-01-15 10:12:21.462 MobileSpecTest[1905:907] [LOG] Started exec
benchmark with payload length: 1
2013-01-15 10:12:22.458 MobileSpecTest[1905:907] [LOG] Calls per second: 26=
7
2013-01-15 10:12:32.212 MobileSpecTest[1905:907] [LOG] Started exec
benchmark with payload length: 32000
2013-01-15 10:12:37.204 MobileSpecTest[1905:907] [LOG] Calls per second:
15.18784972022382
2013-01-15 10:12:38.898 MobileSpecTest[1905:907] [LOG] Started exec
benchmark with payload length: 32000
2013-01-15 10:12:43.897 MobileSpecTest[1905:907] [LOG] Calls per second:
15.163607342378292
2013-01-15 10:12:51.802 MobileSpecTest[1905:907] [LOG] Started exec
benchmark with payload length: 32
2013-01-15 10:12:56.801 MobileSpecTest[1905:907] [LOG] Calls per second:
261.8952419032387
2013-01-15 10:12:58.534 MobileSpecTest[1905:907] [LOG] Started exec
benchmark with payload length: 32
2013-01-15 10:13:03.533 MobileSpecTest[1905:907] [LOG] Calls per second:
262.89484206317474
2013-01-15 10:14:19.153 MobileSpecTest[1905:907] [LOG] Started exec
benchmark with payload length: 1
2013-01-15 10:14:24.154 MobileSpecTest[1905:907] [LOG] Calls per second:
269.43833699780134
2013-01-15 10:14:27.605 MobileSpecTest[1905:907] [LOG] Started exec
benchmark with payload length: 1
2013-01-15 10:14:32.604 MobileSpecTest[1905:907] [LOG] Calls per second:
272.34553089382126
2013-01-15 10:14:42.134 MobileSpecTest[1905:907] [LOG] Started exec
benchmark with payload length: 1024
2013-01-15 10:14:47.132 MobileSpecTest[1905:907] [LOG] Calls per second:
173.6
2013-01-15 10:14:49.217 MobileSpecTest[1905:907] [LOG] Started exec
benchmark with payload length: 1024
2013-01-15 10:14:54.216 MobileSpecTest[1905:907] [LOG] Calls per second:
173.8
2013-01-15 10:14:55.518 MobileSpecTest[1905:907] [LOG] Started exec
benchmark with payload length: 1024
2013-01-15 10:15:00.520 MobileSpecTest[1905:907] [LOG] Calls per second:
173.22677322677322


A note about the data: I was using bytes from 0..255 evenly distributed,
and the JSON serialization of that looks
like: "\u0000\u0001\u0002\u0003\u0004\u0005\u0006\u0007\b\t\n\u000b\f\r\u00=
0e\u000f\u0010\u0011\u0012\u0013\u0014\u0015\u0016\u0017\u0018\u0019\u001a\=
u001b\u001c\u001d\u001e\u001f
!\"#$%&'()*+,-./0123456789:;<=3D>?@ABCDEFGHIJKLMNOPQRSTUVWXYZ[\\]^_`abcdefg=
hijklmnopqrstuvwxyz{|}~=7F=80=81=82=83=84
=86=87=88=89=8A=8B=8C=8D=8E=8F=90=91=92=93=94=95=96=97=98=99=9A=9B=9C=9D=9E=
=9F
=A1=A2=A3=A4=A5=A6=A7=A8=A9=AA=AB=AC=AD=AE=AF=B0=B1=B2=B3=B4=B5=B6=B7=B8=B9=
=BA=BB=BC=BD=BE=BF=C0=C1=C2=C3=C4=C5=C6=C7=C8=C9=CA=CB=CC=CD=CE=CF=D0=D1=D2=
=D3=D4=D5=D6=D7=D8=D9=DA=DB=DC=DD=DE=DF=E0=E1=E2=E3=E4=E5=E6=E7=E8=E9=EA=EB=
=EC=ED=EE=EF=F0=F1=F2=F3=F4=F5=F6=F7=F8=F9=FA=FB=FC=FD=FE=FF"

Which is a 400 character length string.  Base64 encoding 256 characters is
a 342 character string.  However, if the data were not evenly distributed,
and instead consisted mostly of readable characters (as is the case with
many protocols) then non-base64 encoded would be faster.

I've left the base64 encoded version, assuming binary data will be random,
and also because we already support sending raw strings across the bridge,
so a plugin developer can do that if its more efficient.

Either way, this is terribly slow, and I'll have to start getting creative.

Finally, there is a bug where it seems that data larger than ~64k wont
transfer across the bridge at all.  Andrew, is there a known limit to how
much payload exec can send across?

-Michal


On Wed, Jan 9, 2013 at 3:57 PM, Don Coleman <don.coleman@gmail.com> wrote:

> For the phonegap-nfc plugin I send binary data between native and
> javascript as a byte array in JSON.
>
>     static JSONArray byteArrayToJSON(byte[] bytes) {
>         JSONArray json =3D new JSONArray();
>         for (int i =3D 0; i < bytes.length; i++) {
>             json.put(bytes[i]);
>         }
>         return json;
>     }
>
>
> On Wed, Jan 9, 2013 at 3:00 PM, Andrew Grieve <agrieve@chromium.org>
> wrote:
> >
> > On Wed, Jan 9, 2013 at 10:15 AM, Michal Mocny <mmocny@chromium.org>
> wrote:
> >
> > > On Tue, Jan 8, 2013 at 10:22 PM, Andrew Grieve <agrieve@chromium.org>
> > > 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 i=
t
> will
> > > > be tough to make this work. Most platforms assume that you can past=
e
> the
> > > > JSON into an eval / JSON.parse, and it will come out correctly. Tha=
t
> > > 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. F=
or
> > > > ArrayBuffers, maybe we can passing the usual payload plus an option=
al
> > > > 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 whic=
h
> is
> > > the one and only ArrayBuffer?
> > >
> > > I propose yet another option, maybe you can any number of ArrayBuffer=
s
> 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 <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].  Teas=
er
> > > > video:
> > > > > > https://docs.google.com/open?id=3D0B0UdPHoQPXheTzhTZXZHUlpGWHM =
(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 exe=
c
> 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 semanti=
c
> > > > > > 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/plugin=
s
> > > > > > [3] https://github.com/flackr/circ
> > > > > >
> > > > >
> > > >
> > >
>

--047d7b10cbcbbc308904d3556884--