Crete architecture discussions notes

From wiki.gpii
Jump to: navigation, search

Windows work

  • Some settings on Windows appear impossible to change programmatically:
    • font size <HENS> -- high priority
      • Drop attempting to change the font size. Instead we should change the screen resolution
    • contrast/theme changing <HENS / ANTVANIG>
      • We need to make sure that our current high-contrast works proper
      • Examine this: rundll32.exe %SystemRoot%\system32\shell32.dll,Control_RunDLL %SystemRoot%\system32\desk.cpl desk,@Themes /Action:OpenTheme /file:"C:\Windows\Resources\Themes\aero.theme"
  • Taskkill.exe <HENS>
  • remaining SPI (keyboard settings mostly) <HENS / ANTVANIG>
  • remaining magnifier setting <HENS>
  • consider support for OS speech settings (used by eg. maavis) - <SLIM>
  • Volume <HENS>
  • RFID reader <SLIM>

Device Reporter:

  • Report what solutions are installed on the system (GPII-413)
    • For now we need OS specific tests for each platform implementation.
    • Antranig needs to review existing pull requests
    • Steve needs to code the windows
      • Antranig to review once done
  • Should be possible to schedule the device reporter to regularly scan the system (GPII-415)
    • Assigned to post-production as we dont think this will be necessary in the short/medium term future .. reassigned to fix-for "post-production"
  • We need to be able to detect running solutions (GPII-442)
    • In the solution solution registry, the executable name of the process should be declared so it's usable for stopping processes
    • We need a component that continuously keeps track of the running/stopped processes in the system (based on the solutions registry info) and fires events when solutions we know about appear or disappear
    • The component to track solution processes should be cross platform along with the event system
    • We need platform specific plugins that will generate JSON structures (lists of relevant running processes on the system) - this information will be passed on to the cross-platform code, which will compare a JSON structure with it's predecessor and fire events in case of changes

Nomination of commit access / governance

  • Colin will create the governance document within one week, or else the first step of Kasparnet world domination will be unleashed: GPII Technical Governance.

Github history deletion

  • Figure out a way to rebase the repository without destroying the commit hashes. We need to get rid of the "pilot" branch of universal <JUSTIN>

Kaspers ontology server pull request:

  • Any ontologized preferences are equivalent to any other ones, but any application specific term are completely independent of any ontologized terms or any other application specific term and as many of these can appear in an NP set as we can discover values for.
  • It is the job of the matchmaker to decide whether to consult an application specific term or an ontologized one.
  • Transformation policies should be located in a separate part of the document, this includes:
    • Priority of settings
    • Whether the system is allowed to infer things from a specific preference?
    • Other security/privacy settings
  • We have need for:
    • priority record assigned to any application specific block of setting

Questions:

  • Do we need to modify the flat format, as we no longer have conditions for each specific preference?
  • What's the format that we want to use for the transformation policies
  • How about the ability to define (as user) what 'importance level' a setting/application has: i.e. this setting is a requirement for me to use the system, this setting is a preferred/convenient setting
  • How about the ability to defined that a common term should be applied to an application, and the same common term should have a different value applied to a different application.

For the whole follow up on this topic, see: Architectural Notes About the Needs and Preferences Set Format.