- Where is the details on the solution stored? (Is it in the solution reporter, or is there some alternative store, e.g. on the web? .. details in this context is: solution name, signature/identifier, version number, parameter listing, default settings, transformations)
- Who maintains(/validates?) the solution information?
- What is the exact role of the solution reporter? Is it only to report what solutions are available on the system (which is basically program name and version pairs)? or is it to report all the data related to a solution - e.g. programs, transformations definitions, default settings values?
- How are transformations defined? (JSON?)
- Where are transformations stored?
- Who maintains translation rules?
- Are transformation in the central repository (e.g. core->core, live->core, live->live, and core->live translations) generic? do they exist? if so who maintains? (e.g. core[high contrast] -> (core[foreground], core[background])), where do we document these?
- How is a SALH defined? How does it relate to a specific AT? How is it defined in the solutions reporter payload (or solution registry payload)
- How do launch manager and SALH communicate? Is each SALH a separate node? or rather a module in the launch manager? something third?
- It might make sense to build either components to or generic OS level SALHs that are able to handle: events from registry combined with text files/proprietary files. Basically a SALH where the implementer adds the application specific conversion (from json object to flat text file, XML, proprietary, whatever and vice versa). I imagine many implementers want to keep their own text files with settings, but would like to be able to hook up to the event system as well as take advantage of the preferences translation/transformation of GPII.
- Is every component a separate node.js server, or just modules listening to different URLs?
- Can we have native components without a node.js server/module (e.g. user listener)?
- How do we secure that other programs wont abuse the architecture by sending all sorts of bummer payloads to the components. E.g., send bogus preferences to flow-manager (to send to preferences, server), send bogus commands to the launch manager, resulting in the launching of all sorts of AT, etc.
- What is involved in making an application compatible with GPII? SALH, Launch Manager, Solution reporter, translation table, solution registry?
- What do we the SP3 folks need from us to get started (basic blob save)? Info on Windows SALH vs their own SALH?
- What do the SP3 folks need from us to implement proper settings? list of current core/live settings? specs on creating translation tables?
- What do we need from the SP3 folks to have GPII work with their product? solution registry? translation table? SALH specs?
- What exactly do RFID (and other) user listener implementers need from us? API to flow manager, perhaps best practices/guidelines, anything else?
- How are things like easy1 communicator, UIOptions, etc. represented in solution registry? How and when are they run?
- Is the launch manager OS specific or is it rather the SALHs? (guessing SALH?)
- Phones: What user listener in first implementation for phones?
- Phones: Is the remaining architecture (e.g. node.js, etc) viable for phones?
- How widely is gsettings used, what are alternatives/solution in KDE/other distributions? (emergya?)
- Should we get common development environment (e.g. a VM) set up for Boulder?
- Anything currently not ready that we need for Boulder?
- Microsoft: Will we be implementing prototypes of all the windows components of the architecture? What info do they need to be able to start work on their side? What information do we need from them to make sure our planned approach is sound?