web staff: log on workstations/printing

Signed-off-by: Bill Erickson <berick@esilibrary.com>

diff --git a/web-staff-log.txt b/web-staff-log.txt
index 88c1693..169ca9e 100644 (file)
--- a/web-staff-log.txt
+++ b/web-staff-log.txt
@@ -544,7 +544,89 @@ perfectly happy to work with functions intead of attributes.
 <div>Username: {{patron().usrname()}}</div>
 -----------------------------------------------------------------------------
 
- 
+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...
 ----------------