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
