capawesome-team / capacitor-mlkit

⚡️ ML Kit plugins for Capacitor. Supports Android and iOS.
https://capawesome.io/plugins/mlkit/
Apache License 2.0
147 stars 43 forks source link

feat(barcode-scanning): support the Web platform #20

Open piotr-cz opened 1 year ago

piotr-cz commented 1 year ago

Is your feature request related to a problem? Please describe:

N/A

Describe the solution you'd like:

As in description.

Documentation: mdn > Barcode Detection API Demo: https://whatpwacando.today/barcode

Describe alternatives you've considered:

N/A

Additional context:

N/A

thegnuu commented 1 year ago

@robingenz I can have a look at this if you want :) As you mentioned in our discussion you already have a standalone component relying on BarcodeDetector, unfortunately, support of BarcodeDetector is not optimal at the moment (https://caniuse.com/?search=BarcodeDetector).

My idea would be to use https://github.com/undecaf/barcode-detector-polyfill, I was already in contact with the guys over there to allow bundling of zbar-wasm which is possible now, and I think using a polyfill for not supported browsers would be a good idea at the current stage, what do you think about this? This might be a bit of an overhead but it should allow better and broader usage of this implementation and reduce "web platform usage" issues.

robingenz commented 1 year ago

@thegnuu That sounds like a great idea. What about the license? As far as I can see https://github.com/mchehab/zbar is licensed under LGPL-2.1 and therefore not compatible with Apache-2.0.

thegnuu commented 1 year ago

@robingenz I am not entirely sure, to be honest. There was an issue over there https://github.com/undecaf/barcode-detector-polyfill/issues/2 and I think we should be able to use the plugin and bundle it according to this, but I am by far no license expert ;)

robingenz commented 1 year ago

@thegnuu Unfortunately, I am not an expert either. As far as I understand it, it gets complicated as soon as the LGPL source code is linked statically (see https://stackoverflow.com/a/10179181/6731412), which should be the case since the library is compiled into the app as part of the build process.

For example, another plugin author recently switched to the MPL license as there were concerns (see https://github.com/Cap-go/capacitor-updater/issues/7#issuecomment-1454893916).

robingenz commented 1 year ago

For example, another plugin author recently switched to the MPL license as there were concerns (see Cap-go/capacitor-updater#7 (comment)).

@thegnuu I just read about the MPL license and see problems there as well:

3.2. Distribution of Executable Form If You distribute Covered Software in Executable Form then:

such Covered Software must also be made available in Source Code Form, as described in Section 3.1, and You must > inform recipients of the Executable Form how they can obtain a copy of such Source Code Form by reasonable means in a timely manner, at a charge no more than the cost of distribution to the recipient; and

You may distribute such Executable Form under the terms of this License, or sublicense it under different terms, provided that the license for the Executable Form does not attempt to limit or alter the recipients’ rights in the Source Code Form under this License.

Source

thegnuu commented 1 year ago

I see, I see. Another idea would be to just implement BarcodeDetector within this plugin and properly document it like this. If someone needs to use it in a not supported browser, they can implement the initialization of the polyfill on their end. Since there are multiple polyfills for BarcodeDetector (e.g. https://github.com/xulihang/barcode-detector-polyfill) this would allow each dev to choose the version they want.

It's a more generic approach of course and might not work out of the box on each browser, but it would get us around the "license struggles" and add more flexibility for the devs. Adding a polyfill depending on zxing like the example in this comment seems not to be the best idea IMHO.

robingenz commented 1 year ago

I see, I see. Another idea would be to just implement BarcodeDetector within this plugin and properly document it like this. If someone needs to use it in a not supported browser, they can implement the initialization of the polyfill on their end. Since there are multiple polyfills for BarcodeDetector (e.g. xulihang/barcode-detector-polyfill) this would allow each dev to choose the version they want.

Yes, i think this is the best solution atm. Any PR is welcome. Otherwise, I would put it on my todo list next month.

piotr-cz commented 1 year ago

My feature request was initially about adding just native Barcode Detection API for web platform (even with support only on Chromium browsers). Adding a note in docs about polyfills is definitely good idea.

thegnuu commented 1 year ago

I think this makes sense yes, unfortunately I have a really busy week, but maybe I will find some time to start the implementation.

robingenz commented 1 year ago

@thegnuu I had some time on the train today and started with the implementation, see #52.

maelp commented 1 year ago

Perhaps this code could be useful? It handles Datamatrix https://github.com/rxing-core/rxing-wasm/tree/main