I don't see any problem with it as long as existing plugins (core and third-party) don't break (unless we need to deprecate anything of course)
On Fri, Jan 18, 2013 at 11:55 AM, Michal Mocny <mmo...@google.com> wrote: > I've filed https://issues.apache.org/jira/browse/CB-2239 but wanted to get > feedback here in case there a simpler solution to this problem. > > Basically: I've recently added support for ArrayBuffer argument type across > iOS exec bridge and Braden added the same to Android. > > However, while working on a plugin to make use of this feature (socket), we > found that sound plugin calls expect to send an ArrayBuffer back along with > over values. > > We considered adding a special bucket for ArrayBuffer return values to the > bridge, so that you can send a normal result + ArrayBuffer, but decided > that wasn't scalable since we may want more custom non-json serializable > types in the future. > > We decided the best option was to allow returning a list of "cordova bridge > supported types", which includes everything we have had until now + > ArrayBuffer + whatever we add in the future. > > This shouldn't be a big change, existing plugins need not change at all, > and it also opens up the possibility to do some interesting encodings for > return values whenever JSON isn't the most efficient (we do some of this on > android already). > > -Michal >
