New API proposal: Document Scan

[Paul Stewart]

I have a new API I'd like to have reviewed. This provides a method
for performing paper document scanning. The design doc for this
feature is at https://docs.google.com/a/google.com/document/d/1x_Iu8EKEUL8Mc35t22xUguh1cpTiPITgDR6L7S6VyGQ
, and a CL displaying the details of the API is at
https://codereview.chromium.org/286933006/

[Mustafa Emre Acer]

I can't seem to comment on the doc so listing a couple of questions/thoughts here specifically about the CRX bits:

- Is this API going to be public, can any extension/app use it? If so you'd want to add a permission for it.

- Historically extension/app APIs that had methods to list and access devices have had two separate permissions for these two operations. I think a single one is sufficient for this API though (e.g. "documentScan" or something like that).

- You might also consider designing a UI for this API so that the user gets to pick the scanning device, sets the parameters and scans the document all through native Chrome UI without passing anything to the API, and the API only gets the end result.

To unsubscribe from this group and stop receiving emails from it, send an email to apps-dev+u...@chromium.org.

[Benjamin Kalman]

IIRC the cloud print people were work a general framework for interacting with devices, which (IIRC) included ways to read from them. How does this related?

[Benjamin Kalman]

(Picking this up again after some offline discussion)

The design doc is very implementation focused and I'd rather see the API framed in terms of a formal proposal.

[Paul Stewart]

I've created a formal proposal per the template at
https://docs.google.com/a/chromium.org/document/d/1FkgGF3l8wcK9SWllPGHHGwWlrEXqyh9jauHHFKiCSnw

[Paul Stewart]

I'm not sure how you do a "PTAL" in Google Docs, so I'm pinging here to indicate that I've incorporated suggestions (so far no details on web API vs Chrome) and updated the IDL in my CL to match.  The rest of the implementation (e.g., the rendering of the new scan UI elements) is lagging though.

[Reilly Grant]

Unless more information about the scanner is made available through the API the scan options parameter is not very useful. It would better divide responsibilities if the app provided only a hint to the scanner UI (provided by Chrome or a 3rd party "driver" extension) about what kind of object is about to be scanned and what format is expected (document to PDF, photo to JPEG, etc.) and let the rest of the parameters be set out of band (probably with sensible defaults from the hardware plus tweaks from the user).

I think this would pair very well with an API that allowed scanner manufacturers to write drivers as extensions using the USB API.

~ Reilly

[Paul Stewart]

True.  I'll scrap the options entirely, have the application provide a list of mime types it can handle, and have the API return what mime type the image(s) are encoded in.

[Paul Stewart]

Friendly ping.  I think I've addressed the IDL issues, and from an API perspective I believe things are streamlined.  The linked design docs have mocks for the scanning UI.  I'm checking to see if it's okay to move forward with the implementation.

[Reilly Grant]

lgtm from an API perspective.

[Mustafa Emre Acer]

Hi Paul,

I see two documents in this thread (google.com and chromium.org) and the contents are different. The one for google.com has the UI mocks, is it the latest proposal?

[Mustafa Emre Acer]

Ah, never mind. Looks like the google.com doc points to the chromium.org doc which contains the API proposal.

[Mustafa Emre Acer]

Security lgtm.

[Paul Stewart]

One last minor change to the IDL: We need to be able to return multiple images so the ScanCallback now takes an array of DOMString.  Sorry for the late change. 

[Benjamin Kalman]

lgtm but I made some nits on the API itself. I would have liked to see this as a web API, what happened to that discussion (if any)?