From e39c9923dcf01d1566b5a877712b565bfc490b80 Mon Sep 17 00:00:00 2001 From: Bill Erickson Date: Thu, 15 Jun 2017 11:08:59 -0400 Subject: [PATCH] html version Signed-off-by: Bill Erickson --- browser_client.html | 16798 ++++++++++++++++++++++++++++++++++++++++++++++++++ 1 file changed, 16798 insertions(+) create mode 100644 browser_client.html diff --git a/browser_client.html b/browser_client.html new file mode 100644 index 000000000..25ecf572e --- /dev/null +++ b/browser_client.html @@ -0,0 +1,16798 @@ + + + + +A Browser-Based Evergreen Staff Client + + + + + + + + + +
+

What’s all this, now?

+
+
    +
  • + +XULRunner is the framework on which we built the Evergreen staff client. + +
    • +
  • + +"XULRunner is a Mozilla runtime package that can be used to bootstrap + XUL+XPCOM applications that are as rich as Firefox and Thunderbird." +  — XULRunner Project Home Page + +
    • +
  • + +https://developer.mozilla.org/en-US/docs/XULRunner_Hall_of_Fame + +
    • +
  • + +Version 14 of XULRunner, required by Evergreen, was released July 2012. + +
    • +
  • + +As of February, the latest version of XULRunner is version 28. + +
    • +
  • + +14 releases of security fixes, bug fixes, speed improvements, and + features we can’t use. + +
    • +
+
+
+
+

Why Can’t We Update XULRunner?

+
+

+Used The Documented API +

+

* Consarn ye, XULRunner!

+
+
+
+

Why Can’t We Update XULRunner?

+
+
    +
  • + +We’ve been using XULRunner like a development platform with a stable + API and set of rules. + +
    • +
  • + +"XULRunner is a delivery vehicle for the XUL toolkit, which is not a + frozen API. It is an API that has historically evolved over time, and it + will likely continue to evolve for some time to come. While people agree + that we need to stablize that API, it will not happen overnight." +  — XULRunner Development Plan Docs + +
    • +
+
+
+
+

The Big Lost Features of XULRunner

+
+
    +
  • + +Remote XUL + +
      +
    • + +Gives XULRunner the power to read UI templates from the server + +
      • +
    • + +Changes to server-hosted template files are applied to the client + without the need for desktop application updates. + +
      • +
    • + +"Support for remote XUL has long been a potential security concern; + support for it was disabled in Gecko 2.0." —  Remote XUL Docs + +
      • +
    +
    • +
  • + +E4X (ECMAScript for XML) + +
      +
    • + +Used by MARC Editor + +
      • +
    • + +"E4X, an ancient JavaScript extension, has been removed. Implemented + only in Gecko, it never got significant traction (bug 788293)." —  Firefox 21 Site Compatibility + +
      • +
    +
    • +
  • + +multipart/x-mixed-replace messages + +
      +
    • + +Streaming responses + +
      • +
    • + +"Support for the multipart property and multipart/x-mixed-replace + responses has been removed from XMLHttpRequest. This was a + Firefox-only feature that was never standardized." —  Firefox 22 Site Compatibility + +
      • +
    +
    • +
+
+
+
+

What do we do about it?

+
+
    +
  • + +We have a significant amount of work to do, regardless of how we proceed. + +
    • +
  • + +Why not take this opportunity to reconsider how the client + should operate? + +
    • +
  • + +After some lively debate among the community, we have decided now is the + time to move toward a web browser-based staff client. + +
    • +
+
+
+
+

What’s So Great Web Browsers?

+
+
    +
  • + +Remote updates + +
    • +
  • + +The browser is the de facto client development environment. + +
    • +
  • + +Aggressive competition between browsers + +
    • +
  • + +Your average developer is more likely to have experience with HTML + than XUL. + +
    • +
  • + +Most of our problems have already been solved. + +
    • +
  • + +Browser interfaces can work on mobile devices. + +
      +
    • + +Inventory on a Nexus? + +
      • +
    • + +Real-time holds pull list on an iPad? + +
      • +
    • + +Running reports in the browser built into your refrigerator? + +
      • +
    +
    • +
  • + +Browser Features are designed, documented, and implemented by a diverse + groups of individuals, organizations, and standards bodies (w3c, etc.) + +
    • +
  • + +Browser support for a given feature is a good litmus test for long-term + viability. + +
    • +
  • + +Good support for assistive technologies, like screen readers, etc. + +
    • +
  • + +Existing, proven tools for local template customization and translations. + +
    • +
+
+
+
+

What’s So Great Web Browsers?

+
+
    +
  • + +Ease of moving between different Evergreen servers (production servers, + test servers, migration servers, etc.) + +
    • +
  • + +It’s easy to create deep links to specific resources (e.g. patrons) + +
    • +
  • + +Supports multi-tab interfaces + +
    • +
  • + +Bonus: Much of the staff client is already developed as individual web + pages. + +
    • +
+
+
+
+

What Challenges Come with Using a Browser?

+
+
    +
  • + +Seemlessly printing to multiple printers + +
    • +
  • + +Secure file storage + +
      +
    • + +offline transactions + +
      • +
    • + +workstation registrations + +
      • +
    +
    • +
  • + +Interacting with 3rd-party services running on the desktop. + +
      +
    • + +RFID pad + +
      • +
    +
    • +
+
+
+
+

What do we do about this?

+
+
    +
  • + +Buid a small, standalone service ("shim"), which runs on the desktop. + +
      +
    • + +Talking to printers + +
      • +
    • + +Reading/Writing files + +
      • +
    • + +Potentially interact with 3rd-party applications + +
      • +
    +
    • +
  • + +The goal is have a small, stable API that requires infrequent updates. + +
    • +
  • + +Only required by clients that need these features. + +
    • +
  • + +HACKFEST UPDATE: could also be run as a shared service, + accessible over the local network to workstations and mobile + devices, so each can print (and maybe more) to a single instance. + +
    • +
  • + +If built correctly, it could used by other systems, like Koha. + +
    • +
+
+
+
+

Staff Client Prototype Project

+
+ +
+
+
+

Staff Client Prototype Project

+
+

+Patron Search +

+
+
+
+

Development Components

+
+ +
+
+
+

Development Components

+
+
    +
  • + +Java / Jetty for the Print and Storage + service + +
      +
    • + +Java is portable and has flexible printer support. + +
      • +
    • + +Jetty is a small "Servlet Engine and HTTP Server". + +
      • +
    • + +Browser can communicate directly with Jetty over HTTP / WebSockets. + +
      • +
    +
    • +
  • + +WebSockets + +
      +
    • + +Bi-directional, streaming, long-lived connections + +
      • +
    • + +Replacement (and then some) for multipart/x-mixed-replace + +
      • +
    • + +Blog Series + +
      • +
    +
    • +
+
+
+
+

WebSockets Streaming Example

+
+

+Patron Search +

+

XMLHttpRequest requires 102 OpenSRF messages; WebSockets requires 51.

+
+
+
+

Let’s Build This Thing

+
+

http://www.flickr.com/photos/evergreen-ils/3182703496/in/photostream/

+

+ACQ Scribbles +

+
+
+
+

Guiding Principles for the Project

+
+

¡Muy Rapido!

+
    +
  • + +Reduce the amount of time supporting two systems + +
    • +
  • + +Avoiding feature drift and feature locks + +
    • +
+
+
+
+

Guiding Principles for the Project

+
+
    +
  • + +Port existing features from XUL to HTML, as directly as + possible, without adding new features along the way + +
    • +
  • + +Only XUL interfaces will be wholly rebuilt. Existing HTML interfaces + (conify, acq, vandelay, etc.) will be integrated as-is. + +
    • +
  • + +As each sprint begins, the community will be placing restrictions on + features added to the analogous module within the XUL client. + +
      +
    • + +Avoid duplication of effort + +
      • +
    • + +Encourage development and use of the new interface. + +
      • +
    +
    • +
+
+
+
+

Proposed Timeline

+
+
+ ++++ + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + + +
Sprint Modules Estimated Time

1

Base Components (WebSockets, Grids, etc.) and Circulation

18 weeks

2

Cataloging, z39.50 , and Authorities

12 weeks

3

Acquisitions and Serials

6 weeks

4

Reporting and Admin

7 weeks

5

Booking, Offline, Odds and Ends

8 weeks

6

Bug Fixing / Integration

6 weeks

+
+
+
+
+

Sprint #1 Progress

+
+
    +
  • + +Dev Notes + +
    • +
  • + +WebSockets code complete and call for testing + [LP#1268619] + +
      +
    • + +Using WebSockets by default in the staff UI + +
      • +
    +
    • +
  • + +Proof of concept Print/Store service + ("Hatch") + +
    • +
  • + +Display Grids + +
    • +
+
+
+
+

Sprint #1 Pending Code, Research, and Questions

+
+
    +
  • + +JS integration of print/store server + +
    • +
  • + +JS components for keyboard shortcuts and navigation + +
    • +
  • + +More Grid work + +
    • +
  • + +Integrating existing HTML UIs with browser client + +
    • +
  • + +Integrating the TPAC with the browser client + +
    • +
  • + +Possibility of Integrating web UIs into XUL to ease integration + +
    • +
+
+
+
+

Development Partners

+
+
    +
  • + +Sprint #1 - fully funded! + +
      +
    • + +BC SITKA + +
      • +
    • + +Bibliomation + +
      • +
    • + +C/W Mars + +
      • +
    • + +GPLS PINES + +
      • +
    • + +Howe Library + +
      • +
    • + +MassLNC + +
      • +
    • + +PaILS + +
      • +
    • + +Pioneer + +
      • +
    • + +SC Lends + +
      • +
    +
    • +
  • + +Sprint #2 + +
      +
    • + +Grand Rapids Public Library + +
      • +
    • + +NC Cardinal + +
      • +
    +
    • +
+
+
+
+

Comments and Questions

+
+

Bill Erickson <berick@esilibrary.com>

+
+
+ + -- 2.11.0