>> My only reservation is that it is a questionable api imho, converting binary to text just to pass it through the bridge is computationally expensive and ram intensive and better cameras continue to make it worse.
Regarding this, I think we can generally recommend in the documentation to use the base64 API option in case of small images (and it is up to the app developers to decide based on the problem that they are trying to solve). What do you think? On Wed, Feb 27, 2019 at 5:17 AM Jesse <purplecabb...@gmail.com> wrote: > I think I am okay with the breaking change, as long as we update major > My only reservation is that it is a questionable api imho, converting > binary to text just to pass it through the bridge is computationally > expensive and ram intensive and better cameras continue to make it worse. > > > On Feb 27, 2019, at 1:37 AM, julio cesar sanchez <jcesarmob...@gmail.com> > wrote: > > > > I’m +1 to changing it and doing a major release. > > > > It was called data url but it’s not a data url, that’s a bug that has > > become “feature”. > > I think we should have the new type but that returns current string and > > make data url return the real data url and document it on the breaking > > changes. > > > > > > El miércoles, 27 de febrero de 2019, Oliver Salzburg < > > oliver.salzb...@gmail.com> escribió: > > > >> I don't think the behavior should be changed. If anything, just > introduce > >> another type that has the prefix. And maybe add an alias for the > existing > >> type to make the differences clearer. > >> > >>> On 27/02/2019 03:51, Hazem Saleh wrote: > >>> > >>> Hello Team, > >>> > >>> When calling navigator.camera.getPicture with destinationType set to > >>> Camera.DestinationType.DATA_URL, the success function is called with > the > >>> base64 encoded data while it should has suitable data URL format on the > >>> following form: > >>> > >>> data:[<mediatype>][;base64],<data> > >>> > >>> > >>> It is an old issue in the library and it was previously reported under: > >>> https://issues.apache.org/jira/browse/CB-9819 > >>> > >>> And recently, it was also reported by one of the library users: > >>> https://github.com/apache/cordova-plugin-camera/issues/420 > >>> > >>> I have a solution for this problem in Android[1], and I can create a > >>> similar one for iOS and windows platform but my question is, Do we > really > >>> want to support this since it is a breaking change as in all older > >>> versions > >>> of Cordova, a base64 encoded data was always sent, and definitely all > >>> documentation is needed to be updated. > >>> > >>> [OT] I'm sending this email since Julio asked me to post this proposal > >>> here > >>> in a GitHub issue discussion. > >>> > >>> Thanks > >>> > >>> [1] > >>> https://github.com/hazems/cordova-plugin-camera/commit/e6609 > >>> c0b6a590a30ef7802826888693142576bee > >>> > >>> > >> --------------------------------------------------------------------- > >> To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > >> For additional commands, e-mail: dev-h...@cordova.apache.org > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > > -- Hazem Saleh