The Library GPII System is an Applied Research project whose goals include implementing the GPII and related technologies in a full production environment for deployment in Libraries and other environments. This page serves as a home and launch page for the technical details required during the development of the project.
Our vision for this project is of a device that can be installed in multi-seat computing environments that will actualize the goals of the GPII for production environments. This can be distributed as a standalone product or server box that encompasses the GPII and related technologies that bridge the gaps necessary for the GPII to be used in the real world.
At a very practical and pragmatic level, this means putting lots of thought and design into environment specific concerns such as how Windows machines are flashed and updated, what sorts of licencing concerns there are for using the AT, and access restrictions for user data. The core GPII project provides infrastructure for these types of customization features, and we will be building upon that, and pairing it with other OS and server tooling to provide a full product ready for deployment.
The initial focus for deployments will be community and university library systems. For the most part, the workstations will all be Windows based, and there will be many seats at each library. With that context, there are a number of things the project needs to excel at in order to work smoothly and reliably in this environment. Some of these characteristics are already being developed in GPII, but some of them are new items we need to think about specifically for deploying smoothly in the IT environments of our partners.
- Instant Install
- Licensing Models
- Flexible Connectivity
- Materials and Software
While the GPII has capabilities for unloading configurations when a user logs out of GPII, in a windows deployment environment what may happen more often is that the system will reflash itself to a previous or saved state when a user logs out. Additionally, there may be numerable preloaded flash states that we keep on hand for different users, and part of the LGS tasks will be to facilitate the choosing of which disk image a user should be given upon login.
While the state of the industry may be different going forward, historically there have also been edge cases with the order of installation, configuration, and launching of AT on windows. This has been has granular as various AT's swapping out system level DLL's with custom versions, and editing system registry settings in such a way that the order of AT execution may need to be very specific. These are further reasons why we may need to get in to the business of tracking system images, and matchmaking the appropriate system image based on a users saved GPII preferences.
The GPII is beginning to evolve towards installing AT on various platforms and we will need to continue to push the edge on this for production Windows deployments, including some of the edge cases mentioned in the previous section. Functionality wise we will be exploring 2 models for this:
- Installing all AT's on an image, and enabling them for users on the fly.
- Installing different combinations of AT's on multiple images, and swapping the windows image on the fly when the user logs in.
These particular use cases and requirements still require a deal of investigation and prototyping to see what is feasible given the needs.
Commercial AT's will have a number of licensing models which we need to accommodate. On the most granular level, a particular AT may allow usage with microtransactions, so that the library is only charged when a user needing that solution is logged in to a workstation and it is activitated. On a broader level, some libraries may prefer an annual licensing aggreement so that they can plan their costs ahead of time. We need to plan accordingly in order to handle these in the future.
Some of this work is also undergoing in the Prosperity4All project, so we can leverage and contribute to work going on there.
Our turnkey solution needs to support varying levels of restrictions on ingoing and outgoing activity. This can include downloading AT's and accessibly material, as well as uploading configuration and settings to a cloud server to store a users preferences.
We also need to plan for the ability to be disconnected from the broader internet for varying amounts of time, in areas where there is low bandwidth for infrastructure reasons (an example being rural areas), or that IT policies prevent it.
There are 4 granularities we think about for connectivity:
- Always connected
- Irregularly or unreliably connected
- Seldom connected
- Never connected
Materials and Software
We intend to facilitate access to materials as well as software. This could include methods for discovery of prepared material, as well as on the fly conversion of material using infrastructure services such as robobraile.com. Additionally, this could dovetail with other hardware systems in the library to allow scanning and conversion.
Partners and Libraries
This is still in planning but it's fairly likely we will initially be partnering with a subset of the library system at UW Madison, and University of Michigan. Ideally, our final list will include a public library system, and libraries of various sizes from large/urban to small/rural.
We are currently collecting information from deployment stakeholders. Including information on the Library Technical Requirements page.
Back to the LGS Dashboard