Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

QRCode: add QR data mask to Barcode result #849

Open
wants to merge 1 commit into
base: master
Choose a base branch
from

Conversation

markusfisch
Copy link
Contributor

I forgot to add dataMask to Barcode as well, so clients can access this member.

@axxel
Copy link
Collaborator

axxel commented Oct 14, 2024

Ahh, I was already wondering how your last PR was helping you... The "problem" is that I was fine with adding this info to this "internal" data structure, precisely because it was not affecting the public API. But the bar for me to add a new member to Barcode is substantially higher. I'm afraid, the disussed niche application is not something that I care enough about to justify the maintenance cost across all the wrappers.

This subject brought back to memory the old "MetaData" thingy that the upstream code base had. Maybe I would be more convinced if we added something that allowed to easily add "random" stuff, that is only meaningful for certain symbologies, later without changing the API. But it would need to be very simple and generic, like a string containing a JSON object.

What do you think? Are there any other meta-data that you know of which might be interesting to add?

@markusfisch
Copy link
Contributor Author

Good question. I can't think of anything specific at the moment, but there are certainly properties of other symbologies that could be interesting for similar reasons. So I think it's a good idea to transfer such metadata via a generic field so that the maintenance effort remains as low as possible.

Also, the data mask is a very QR Code specific thing, so I can well understand that you would rather not have this element in Barcode. I just did it this way because it was the most simplest solution. But a generic string holding a JSON would also be fine!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

2 participants