Hi,

On Tue, May 13, 2014 at 12:08:51AM -0700, Josh Triplett wrote:
> On Tue, May 13, 2014 at 09:44:26AM +0300, Teodora Băluţă wrote:
> > On Mon, May 12, 2014 at 7:15 PM, Jason Cooper <jason@lakedaemon.net> wrote:
> > > I'd like the URL to be valid (meaning base64 the compressed data) so
> > > that we can get the data to the kernel.org server as easily as possible.
> > > Making the app a requirement for reporting is too onerous for
> > > non-developers.  I see no reason we can't link to (Open in/Install) it
> > > on the webform though.
> > 
> > So from what I can understand, the QR code has an URL that has the
> > base64 of the compressed Oops message. Right? I see three problems
> > with this approach:
> > 
> > - base64 adds about 33% overhead (it's turning 3 octets into 4 encoded
> > characters + padding). One issue with QR codes is that they have a
> > limited amount of characters they can hold so that's why I do the
> > compression in the first place
> 
> Putting base64-encoded data in a URL in a binary-format QR code with 8
> bits per character does indeed waste quite a bit of space.  However, you
> could put base32-encoded data into an alphanumeric-formatted QR code
> with 5.5 bits per character, which would waste very little space.  (Or,
> more efficiently but less conveniently, base40 or so.)
> 

Base32 does sound good until you realize that it requires roughly 20%
more space than Base64 does. We would need some calculations to
decide if we were to go down this path.

> > - besides doing compression in a kernel that's had issues, you add the
> > base64 encoding inside the kernel
> > - you would still use a device with a camera (smartphone, tablet) to
> > scan the QR from the framebuffer, so basically that means an app,
> > right? What is the point of doing the URL validation inside the kernel
> > when an app can do that? It doesn't add to the difficulty of sending
> > the Oops to kernel.org (just one button away)
> 
> Many users will already have a QR-code scanning app installed, and such
> apps always support loading URLs in a browser.
> 

Yes, and having them the requirement of installing an app might make
people turn their heads away from reporting the bug.

> Another possibility to consider: current mobile browsers support the
> HTML Media Capture API, which allows capturing an image from the camera
> from within a file upload control.  Together with a bit of Javascript,
> that would allow app-less oops capturing just by visiting a page and
> using that page to capture the oops image.

I guess this is another way to go provided that devices really do
support it. As far as my device goes it's totally not working. :-)
(Android 2.3.7)

Thanks,
    Levente Kurusa