Support data: uris as used by tagdrop

[xloem]

No description provided.

[xloem]

should we also broadcast the data view intents tagdrop listens for?

[mofosyne]

datauris are based off https://en.wikipedia.org/wiki/Data_URI_scheme and is a purely uri scheme. It encodes in either percent encoding, or base64. Basically not very efficient storage. I only chose it, because how recognizable it is (thus futureproofness) by future programmers, since it is based on a internet standard. And also! because zxing sends intent of any uri it detects, which tagdrop listens for, it would make it easier if people can use their standard zxing barcode reader to scan datauris.

Also the current way I have implemented it, requires the users to accurately scan each code, exactly in the correct sequence. So no possibility of mix scanning of QR codes datauri, in out of order fashion. (via some form of structured appends)

Also, data uri usage of base64 means a 30% overhead compared to direct 8bit binary.

---

Should you do it? Well its not very hard to implement so why not. Its a good approach for small files.

But for larger files, we should probbly try thinking about a more flexible "manifest" QR option.

What's on my mind is that the manifest would also take advantage of zxing android client "schema intent" feature, and would basically contain all the information you need to know on how to treat the sequence of QR codes. e.g.

• Filename?
• Mediatype?
• Compression?
• Encoding?
• Is this an auto stream? If so, what the speed? Is there a beep after each send? Should I ack it somehow?
• How do we order the next few scanned symbols?
  • Is there a "1of4crc256:" on each code?
  • Or maybe we have a known sequence of sha5/md5 hashes to match against?

So how shall we do this? maybe the manifest might look like:

 MANIFEST:{some_json_content_here}

(note: you cannot have spaces in the QR code for the manifest, if it is to be detected as a URI by zxing barcode reader app.)

---

I tried looking at Watchit Gotit. The system is very slick, but can be hard to get the focus right for uncorrupted reading. The way it works is that it has a low rez QR code saying "START", then a high rez sequence of QR codes that takes the format of

FILE:cat_b.gif

followed by some gibberish which is the data I think (or maybe some information about it?), the next sequence of barcodes are just gibberish tho.

So it doesn't actually transfer the mediatype, just the filename. And i presume you derive the mediatype by the file extension.

Only issue is that getting the order wrong, would lead to file corruption. But since they record a video, ordering is not an issue. Also, it is hard for me to understand from an outsider how to reverse engineer the content. Which doesn't mean much for transferring files. But if you are printing it on paper. Then in a decade, it is likely no-one will have any idea how to decode it.

So yea, we should decide on a manifest. They did get one thing right, in that they encoded a filename, so the receiver doesn't have to type the filename to save.

other approach:

The other approach is to somehow extend the datauri standard to encode everything a "manifest" would already do.

---

tl;dr: datauri is good for text you can shove in to one QR code, or for people who want to do things manually. But we could extend the datauri standard to support extra stuff like filenames. Or create a "MANIFEST:" standard.

[mofosyne]

Oh and here is an issue I made to think about what could be done to extend the datauri syntax mofosyne/tagdrop#2

[mofosyne]

Another thing to note in mofosyne/tagdrop#4 , if supporting transparent datauris.

People may want place the first QR code as data:text/plain, (omitting ;base64 implies that you want percent encoding), and leave the next few sequence of QR codes in plain text with newline characters. If you just put it directly into the browser, the newline characters will mess up the interpretation I am sure. You may want to convert all spaces and newlines to percent encoding to capture these "non" uri characters (and other non uri characters as well... provided you can avoid clashing with other % encoded characters).

This would allow for plaintext markdown files, or any content with newlines.

[mofosyne]

Oh btw, if you want to implement parsing of datauris, this could be a good starting point.

https://github.com/ooxi/jdatauri