extending datauri syntax

[mofosyne]

datauri syntax can be rather limiting. What if you want to split the string over multiple tags? What about adding compression? What if the encoding is in binary?

The general syntax is

 data:[<MIME-type>][;charset=<encoding>][;base64],<data>

We can extend by including:

• [;compress=<compressionScheme>]
  • compression schemes like lzma
• ;base64&lzma
  • better choice I think. More compact.
• [;bin8=x<binarySizeInHex>] OR [;bin8=<binarySizeInInt>]
  • Tells user that the following bytes from next few QR codes are going to be in pure binary?
  • Could be ;octal= instead? Would that be a more accurate wording?
• [;crc8Seq=234&23&34&53&423&23&4]
  • Some way to do structured append via crc checking? Or maybe it should be via sha5 or md5?
• [;seq=<seqNum>of<totalInSeq>]
  • Maybe to emulate structured append?
• [;id=<numberOrLetters>]
  • Maybe to keep similar sequences sets together?
• [;filename=<filename>]
  • optional filename?

So via these extensions, we could make data uri do double duty as a manifest perhaps;

[xloem]

Once you are storing raw binary data in a data: uri I'm not sure any other application will be able to process it, and I'd question the choice to still use the structure of the data: uri here if something else might better do the job. But they'd work.

Note that zxing can be used to process out-of-order structured append codes if you process the SA information by hand from the raw data. But it will not generate them yet.

[mofosyne]

The use of uri. At least for the first QR code you scan, is for the convenience of activating the program from zxing barcode scanner (which would be more convenient than having to open tagdrop or qrstream to scan the same code initially) . The actual binary data can be stored as normal in subsequent QR codes (tho how to work out the order would be a bit of an issue, unless we are relying on users to scan properly in sequence).

But yea, I am leaning towards just baking our own standard. What do you think about using the word "MANIFEST:" as the trigger word for zxing barcode reader to open our program, and storing the settings as a json data structure (unless you have a different idea)?

---

p.s. For structured append, I guess we have to assume users won't know how to generate it. So having the manifest QR code store a sequence of truncated hashes (e.g. md5:[h242,j42j34,53aj]) or optionally for text, a sequence of the first few characters of each barcode sequence (e.g. seq:["#section1","#section2"]) could be more manageable and transparent.

Info about various hash functions