Re: [hpoj-devel] Scan To

[<pa...@rc...>]

Hi, Allen.

Allen Barnett wrote:
> Hmm. Is listening for PML traps part of the current functionality of
> ptal-mlcd? And does it already implement the registration of
> applications for notification? (Ah, is this what ptal-pml is for?) [Hey,
> I'm getting the hang of all these acronyms.]
Not yet.  The plan is for libptal to provide the PML API and to be responsible
for encoding the request packets and decoding the reply and trap packets.
ptal-mlcd will handle multiple PML sessions from applications and multiplex
the requests, replies, and traps to/from the appropriate application.

> Practically, I think the most useful application of the ScanTo button is
> if you have a number of similar items to scan and the OfficeJet is on
> the other side of the office from the computer. Therefore, if a few
> different settings of color/resolution/etc are common, you could make
> multiple entries in the internal table like: SANE-300BW, SANE-600COLOR,
> and so forth. The user daemon (as suggested below) could even download
> these choices dynamically when it is started.
That might make sense, although it could be problematic to have to limit
yourself to a few combinations of options.

However, this scenario with the scanner across the room (or worse, in another
room) got me thinking.  Assuming you have a lot of documents to scan and no
ADF, you could load the first document and go back to the computer and do a
few preview scans to experiment with settings.  Once you have it set up the
way you like, you could go back to the scanner, push the "start scan"
button for it to scan to out-1.pnm, load the next document, push the button
again to scan to out-2.pnm, etc., until you've scanned everything.  The
problem is that SANE doesn't have provisions for starting a scan based on
input from the device, since the frontend revolves around the GUI, not the
backend (device-specific driver).  However, I suppose it could be possible
to rig up a "Scan-To" daemon to simulate mouse clicks on the "Start Scan"
button in the frontend.  Another possibility would be to modify the backend
to communicate the current settings to the daemon, which would pass those
settings to the non-GUI "scanimage" app when the start-scan button got
pressed.

> Well, my desktop machine is already nightmare of inappropriate /dev
> permissions since I've never bothered to learn enough about PAM to fix
> them properly. For example, anybody logged into the machine can sync my
> Palm. Perhaps I should consider this an opportunity to learn something
> new :-) [I'm thinking that PAM should adjust permissions on the
> ptal-mlcd socket so that only the console user can connect. Or, if there
> is a separate mechanism for registering interest in PML traps, adjusting
> the permissions on that mechanism. Am I totally out in left-field?]
According to the unix(7) manual page, Linux honors the permissions on the
socket for purposes of connecting to it, but other platforms may not.
Even so, I'm sure there would be plenty of situations where you wouldn't
want to restrict access to ptal-mlcd (read: the entire device) to the
console user.

> What other functionality of the OfficeJet is available through PML? It
> might be nice to set the speed dial buttons or dial the FAX phone number
> directly. I take it that there is not extensive documentation on the
> actual capabilities of these devices.
There's a terse PML object list somewhere under the "documentation (old)"
section on the webpage.  I have additional documentation that provides a
little more information, some of which I can give out if needed (but not
post on the web).  I'm considering putting together a small cmdline app
so we can play around with stuff like this once I finish the PML support.

David