From 1b18ed5acbcb126d9e627694777d3a55fe2612ef Mon Sep 17 00:00:00 2001 From: Bill Erickson Date: Tue, 3 Dec 2013 18:10:43 -0500 Subject: [PATCH] web staff: log on workstations/printing Signed-off-by: Bill Erickson --- web-staff-log.txt | 84 ++++++++++++++++++++++++++++++++++++++++++++++++++++++- 1 file changed, 83 insertions(+), 1 deletion(-) diff --git a/web-staff-log.txt b/web-staff-log.txt index 88c1693b7e..169ca9edd6 100644 --- a/web-staff-log.txt +++ b/web-staff-log.txt @@ -544,7 +544,89 @@ perfectly happy to work with functions intead of attributes.
Username: {{patron().usrname()}}
----------------------------------------------------------------------------- - +2013-12-03 What About Workstations? Printing? +---------------------------------------------- + +Why is the workstation optional in the prototype login page? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +I mentioned this briefly toward the bottom of my old "Hey, let's build a +prototype!" +http://yeti.esilibrary.com/dev/pub/EvergreenWebStaffClientPrototype.pdf[proposal]. +I've heard the question again from a number of people, so I'll answer it +here in a little more detail. + +Short answer first, yes, the plan is to continue requiring workstations +for the browser-based client. The fact that they are not required in +the prototype is the result of an unresolved technical hurdle. + +What's the problem, exactly? +~~~~~~~~~~~~~~~~~~~~~~~~~~~~ + +One of the main benefits of XULRunner is that it runs on your computer +as a trusted application. XULRunner can open files on your computer, +create raw network sockets, and it can talk directly to your printers. +Web browsers, being tasked with executing all kinds of untrusted code, +have a whole host of restrictions that prevent that level of access. +This is a good thing for security, but it makes accomplishing some tasks +understandably much more difficult. This lack of access in the browser +may be the biggest challenge we face in developing a browser-based +client. + +There are two classes of problems that we need to resolve: access to +files and access to printers. + +File access is important for things like storing the workstation +information in a way that is not easily deleted on accident and can be +shared between more than one browser. We need the same level of control +for offline transaction data as well. There are probably more... + +Modern browsers will let you store quite a bit of data (~5MB for +localStorage), and in some browsers you can manually raise the storage +limit, but they won't let you control where that data lives or allow +other applications to access the data. They also make it fairly easy to +delete the data en masse within the various debug consoles, which is +obviously bad for files we want to stick around indefinitely. + +For printing, all you can do from the browser is say "print, please" +and then the user is shown a print dialog. Different browsers have +different settings for controlling whether the dialog appears, etc. but +they are non-standard and still not as flexible as we need. What we +need is a way for the web application to send print data to different +printers based on the context of the action, without requiring the user +to manually select the printer each time. + +What's the solution? +~~~~~~~~~~~~~~~~~~~~ + +There are probably multiple solutions. The most promising so far, which +was discussed at the http://goo.gl/oKo5yt[Evergreen Hackaway] is that of +a small service which runs on the client machine independent of the browser +and performs privileged tasks that the browser cannot. It would likely +operate as a small, local web service, accepting connections from clients +(i.e. browsers) on the local machine. Those connections may take the form +of Websocket connections or XMLHttpRequest via +http://en.wikipedia.org/wiki/Cross-origin_resource_sharing[cross-origin resource sharing] +(though, I'm not sure the latter approach would actually work). + +With this approach, we get to resolve all of the browser limitations +with one, cross-platform, browser-agnostic add-on. Depending on how +it's implemented, we may also get to leverage printing APIs which are +more powerful than those found in XULRunner. + +This probably goes without saying, but such an add-on, whatever form +it takes, will *not* be a *requirement* for using the staff client. +One aspect of a browser-based client that I find most appealing is the +ease of access from different devices and locations. If I were using a +tablet, where the add-on is not (or conceivably cannot be) installed, +I would still expect to be able to log in, possibly with a workstation +(via bookmark/URL or typed in), possibly without, and perform, say, a +patron lookup. If I don't need the extended features, I should not be +required to have them installed. + +Finally, it needs a better name than "add-on" (Add-On 2.0!) and it needs +developers/sponsors, and all that fun stuff. + Future Topics... ---------------- -- 2.11.0