Architecture Version 0.1
Overview
As the very first version of architecture, the plan is create a thin vertical slice. While the full stack should be working and this would basically be a first working implementation of the architecture, the components will be simplified to various degrees, and some will even be implemented as hard-coded placeholders.
In short, the system would be something like the following: We are going to implement both the server and client in Fedora 16. The preferences server will be a nodejs server, either with a couchdb holding the preferences, or simply serving hard-coded responses to user requests. If we deem it realistic, a simple preferences wizard will be implemented as well (using UIOptions, this could be very little work). The system will support settings for font size and contrast schemes which are changed according to user preferences on login via user listener and reverted once the user logs out. The user listener will be implemented in the form of a web-based login form. The solution reporter and device characteristics reporter will likely be hardcoded in this first implementation, preferably acting like their fully functional counterparts, but with hardcoded guts which can then later be replaced by something more intelligent.
The purpose is:
- To force us to make some concrete considerations about the architecture, implement/test them and realize if the approach is flawed.
- Decide on close-to-final APIs/documents to be passed between the components. This will allow delegation of and independent work on the individual components.
- To get an early working full stack implementation to serve as a base for future work on the individual components and the general architecture.
- To have an early system for demonstration
Details
General:
Flesh out the general flow of data. That is, from when the user identifies him/herself to the listener, to when the programs/features are actually set up. Involved in this is making example payloads for each relevant steps, as well as assigning responsibilities for what component contact what component and by what means.
Preferences Server
Notes/Short Description: Nodejs, couchdb. Should be able to accept restful requests for user preferences Holds user preferences. Will likely be using a nodejs server with couchdb for storing preferences. Rest API.
Version 0.1:
- Minimum:
- Set up Fedora 16 environment that can hold en emulated “remote server” and a “local server”
- Define document for preference requests
- Define document for returned preferences
- Store the few basic preferences required to demonstrate the decided on SALHs
- Must be implemented to the extend that it will return some preferences when a login is sent - the responses can be hardcoded
- Realistic:
- Set up nodejs & couchdb on “server”
- Decide on a preliminary format for data stored
- Optimistic:
- Be able to save+retrieve proprietary (binary) datablocks
- Be able to save+retrieve regular, proper formatted datablocks
- Allow for storing, retrieving and updating preferences (in the context of managing a profile)
MatchMaker
Notes/Short Description:
MatchMaker will to a large degree be placeholder able to do only a few simple things. It will be able to take a few select preference blocks from server and match them to a few select solutions. In terms of solutions, this will be the gsettings and/or gconf programs of Fedora 16. The exact preferences to handle are to be specified. Input from device characteristics reporter is either to be hard-coded, or not implemented altogether in the context of version 0.1.
Version 0.1:
- Define documents from UserListener
- Define document/format to Launch manager
- Flesh out communication with reporters (environment, device characteristics, solutions). How should this happen?
- Set up MatchMaker
Preferences Editor (Wizard)
Short Description: This will only go into version 0.1 if there is time for it. If any editor is done, this will likey be using UIOptions
Version 0.1: While the editor will be nice to have to easily browse the profile/preferences data etc., this isn’t required of version 0.1. At least not as long as the preferences can be retrieved via a call to the preferences server in some relatively readable format (eg. Json or XML).
User Listeners
Short Description: Will be able implemented in the shape of a web based login form, with a username, password and submit button. If time allows, alternative listeners could be implemented.
Version 0.1 Steps/Goals:
- Minimum:
- Make a regular browser based form login
- Define document format from user listener
- Have the browser send the info to the preferences server (via the MatchMaker?) and trigger the Launch Manager.
- Make an unsuccessful (faulty login) resulting in no retrieval of data and error message
- Set up some means of user log out – and inform launch manager when this happens so we can reset
- Realistic/Optimistic:
- Set up keycombo for launching browser login form
- Create a USB launch version (stick in usb, automagically send uname/pass to server)
- Present login form in a more accessible way (eg. with screen reader)
- Face recog. or the like
- Do windows compatible version
Launch Manager
Short Description: For version 0.1 this will be limited to handling _gsettings/gconf-_tool which in turn will allow changing a large group of features built into gnome. Most importantly this includes font-size and contrast, which are the features targeted for 0.1. This was originally planned to be a nodejs/express server, but we will probably have to reconsider this, as issues will arise with firewalls and company policy are likely to happen.
Version 0.1 Steps/Goals:
- Minimum:
- Handle changing font size in Fedora 16 using gsettings SALH
- Handle changing theme to high contrast (Black on White and vice versa) in Fedora 16 using gsettings SALH
- Decide how to implement launch manager, if it’s not going to be a server
- Define document from matchmaker to launch manager
- Be able to save current settings/state before launching new settings (ie. Save current font size and theme before changing them)
- Be able to restore previous settings/state once user is logged out.
- Optimistic:
- Be able to trigger screen reader
- Be able to trigger onscreen keyboard
- Do a Microsoft version of the SALH (this requires user listener impl. in Microsoft as well)
Declarative SALH
Short Description/Notes: For version 0.1 we will implement a Declarative SALH in the shape of gnomes gsettings configuration tool. This SALH will be able to handle font size and contrast (theme)
Version 0.1 Steps/Goals:
- Minimum:
- Decide on document/API (if any) required to run the SALH
- Be able to change the font size using gsettings
- Be able to change the theme using gsettings
- Save ‘current’ settings before changing according to user settings
- Optimistic:
- Implement screen magnifier in Gnome – Joseph Scheuhammer (IDRC) is doing the Screen Magnifier for the Gnome Desktop.
- Implement on screen reader in Gnome
- Implement font sizes or the like in windows
Solutions Reporter
Description: Unless we have more time than expected, this is likely to be hardcoded. It should report that we have gsettings available and that it is able to change font size and theme.
Version 0.1:
- Minimum:
- In the very first versions, the solutions reporter isn’t strictly required. Instead, the solutions ‘reported’ to the MatchMaker can just be hardcoded.
- The ‘solutions’ reported should be: gsettings and it is able to accommodate font size and contrast settings
- Define document passed from solution reporter to MatchMaker.
- Optimistic:
- Include anything else implemented in the solution report
- Make MS compatible
Device Characteristics Reporter
Description: This is not necessarily required in version 0.1. It might be needed to some extend, if we want to support multiple formats for font-size (point size, dpi, etc) – in which case screen resolution and physical size might be required to calculate the appropriate size. If this is indeed the case we will hard code it.
Version 0.1:
- Minimum:
- Implement a hard coded version if required, or if we deem it would be an advantage to do so to decide on the document sent to the MatchMaker.
- Optimistic:
- If we implement windows version as well, we need to be able to report whether user is running in linux or windows
Potential extensions:
- Screen magnifier
- Alternative user listener (something simple, like a usb stick, etc)
Timeline
WSIS meeting is May 14.
01.20.12:
- Use case - description and documentation
- How do we deal with local code if we dont have a server running
- Flow in architecture, written down from user listener to SALH call and execution to user logout and settings reversion
- Decide how preference server is to be implemented (hardcoded vs. couchdb, how separate from match maker, etc)
- Decide on how Launch Manager is to be implemented
- Decide on how Match Maker is to be implemented (separate from prefs server, etc)
02.01.12:
- Preliminary definitions of documents/APIs of components in architecture
- Environment (server+user) set up in vagrant
- User listener done for the triggering part
02.15.12:
- User listener done for the logout part
- Launch Manager/SALH able to handle font size and contrast under Fedora 16
- Launch Manager/SALH able to revert back to original settings
03.25.12:
- Solution Reporter or Device Characteristics Reporter either implemented or hardcoded to the degree required by match maker in it's current state
- Match Maker working, triggering Launch Manager
04.10.12:
- Full working stack, including reverted settings on user logout
04.15.12:
- Make sure everything is documented
- UIOptions/wizard/editor working (if we decide to implement)
05.01.12:
- Able to do fresh and fully working install and setup by following instructions.
- Everything is working, relatively stable, and in a presentable state.