The downside would be that it would add yet another quirky implementation, while this about not dragging along the existing quirky non-standard implementation. Existing users who don't want to change their code don't need to change anything.
I expect usage of this api is quite low already ( anecdotally ) Here's a couple other reasons the base64 encoded methods are problematic: - missing exif data - possibly incorrect image/jpeg vs image/png, luckily user agents appear to just use it @purplecabbage risingj.com On Fri, Mar 1, 2019 at 12:50 AM Oliver Salzburg <oliver.salzb...@gmail.com> wrote: > What is the downside of just introducing new options and not creating a > breaking change? > And what is the positive impact of this change that it necessitates that > every consumer of the existing API change their code? > > IMHO that has not been made clear enough. > > On 01/03/2019 02:17, Hazem Saleh wrote: > >>> 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 > >> > >> > > --------------------------------------------------------------------- > To unsubscribe, e-mail: dev-unsubscr...@cordova.apache.org > For additional commands, e-mail: dev-h...@cordova.apache.org > >
