Re: [Architecture] Review of the "primary schema" wiki page...

[Antranig Basman]

Thanks for these very helpful suggestions. It is great to have our use of JSON schema reviewed for 
compliance with the developments in it since we originally based our work on it in 2011. I should note that 
the use of propert names containing periods such as "fluid.prefs.textSize" or "#fluid.prefs.textSize" is 
problematic with the current version of Infusion - if these appear in IoC references, the periods will be 
interpreted as property indirections, making it impossible to reference either these properties or anything 
nested within them. Our practice has been to escape these either explicitly, using the "\." syntax, or else 
in an implicit way by replacing them with underscores "_". Do you have a preference between these, or any 
other alternative suggestions?


Cheers,

Antranig

On 14/04/2017 10:03, Tony Atkins wrote:

As agreed in the PCP API meeting, I have been reviewing the "primary schema" 
wiki page for the preferences
framework:

http://docs.fluidproject.org/infusion/development/PrimarySchemaForPreferencesFramework.html

First of all, although I recognize that this is an example, it lacks some 
pretty basic context.  The example
does not make use of the "/$schema/" field
,
 and as
such there is no indication of the fact that this is even a JSON schema, or of 
what version of the standard
we are using.  This should be addressed.  If for example our "/$schema/" field 
indicated that our schema was
written to work with draft v3, it might still reasonably expected to work with 
validators that support newer
versions.

The next biggest thing I notice (as their use is not valid in the root of a 
schema) is that the example
field definitions are "snippets" of schema content rather than a valid schema.  
I'm not arguing that every
example has to be a complete schema, only that we mention the context in which 
an examples would be used.

So, I'm assuming these snippets belong in either the "definitions
" or 
"properties
"
 block of a
schema.  As mentioned in my note to Steve, even if the goal is to describe the 
fields that are accepted in a
particular document type (AKA "properties"), defining the fields in a 
"definitions" block gives the best
options for reuse.  As I also mentioned in my note to Steve, my advice is to make use of 
the "id" field, as
shown in these examples 
.  
Combining
all of the above, the main definitions file might look something like:


{
 "$schema": "http://json-schema.org/schema#;,
 "id": "http://real.site/schemas/preferences.json;,
 "definitions": {
"fluid.prefs.textSize": {
  "id": "#fluid.prefs.textSize",
  "type": "number",
  "default": 1,
  "min": 1,
  "max": 2,
  "multipleOf": 0.1
},
// Remaining defs omitted for brevity
 }
}


Although "/id/" values are not strictly required, using them gives us a simpler 
way to refer to a definition
from another file.  If we are dealing with a file in the same directory (hosted 
or local), we can now either
refer to "/preferences.json/definitions/fluid.prefs.textSize/" (the path 
relative to the root of the
document) or "/preferences.json#fluid.prefs.textSize/" (the "/id/").  Within 
the preferences.json document
itself, once we have "/id/" values, we can use references like 
"/#fluid.prefs.textSize/", which seems
closest to our use of namespaced grades in other contexts.

Even within the snippets, I can see that we are using an older version of the 
standard.  This example has
also been updated to reflect the need to use "/multipleOf
/"
 instead of
the earlier "/divisibleBy/", as discussed in the meeting.

I'll stop there, as I think just looking at the examples highlights enough for 
a single note.  I also plan
to review the JSON schemas (or snippets) in various repos and will comment 
under separate cover.

Cheers,

Tony


___
Architecture mailing list
Architecture@lists.gpii.net
http://lists.gpii.net/mailman/listinfo/architecture



___
Architecture mailing list
Architecture@lists.gpii.net
http://lists.gpii.net/mailman/listinfo/architecture

Re: [Architecture] node_modules

[Antranig Basman]

Yes, that is what I meant - sorry for the confusion.


On 05/07/2017 17:23, Tony Atkins wrote:
> Hi, Antranig.
>
> I assume you meant that /fluid.require("%universal")/ would solve the
> problem?
>
> Cheers,
>
>
> Tony
>
> On Wed, Jul 5, 2017 at 6:03 PM, Antranig Basman
> <antranig.bas...@colorado.edu <mailto:antranig.bas...@colorado.edu>> 
wrote:

>
> Cheers for the question, Gio.
>
> As of the merge of https://github.com/GPII/universal/pull/487
> <https://github.com/GPII/universal/pull/487> fixing GPII-2151, it
> *should* have been the case that all test cases will run properly
> regardless of the position of the checkout. They did at the time of
> the merge - but with the universal truth that functionality which is
> not tested is broken, this condition must have been broken by some
> test cases which were committed since that time (February this year).
>
> The issue is pretty simple to fix up. It is caused by an oddity with
> node module resolution which generally prohibits resolving a module
> name from within itself, unless its parent is named "node_modules".
> There was a lot of code which was a bit slack about this in the old
> days, for example, test code which would issue
>
> require("universal");
>
> from within universal. This is faulty, but still seemed preferable
> to writing what it seems that node authors would have liked, which
> is something uncivilized like
>
> require("../../../../..");
>
> which as well as being incomprehensible will break if the test is
> moved to another directory.
>
> For a while now this has been resolved by the Fluid module system
> API with docs at
> 
http://docs.fluidproject.org/infusion/development/NodeAPI.html#fluid-require-modulename-foreignrequire-namespace-
> 
<http://docs.fluidproject.org/infusion/development/NodeAPI.html#fluid-require-modulename-foreignrequire-namespace->

>
> by replacing the call above with
>
> require("%universal")
>
> the problem is solved, but it is possible that not everyone got the
> memo. If some tests fail, and we care, we should i) reopen the JIRA
> GPII-2151 with a list of the failing ones and after it is fixed ii)
> change our CI for universal so that it checks it out to an ordinary
> directory.
>
> CHeers,
>
> Antranig


___
Architecture mailing list
Architecture@lists.gpii.net
http://lists.gpii.net/mailman/listinfo/architecture

Re: [Architecture] node_modules

[Antranig Basman]

Cheers for the question, Gio.

As of the merge of https://github.com/GPII/universal/pull/487 fixing 
GPII-2151, it *should* have been the case that all test cases will run 
properly regardless of the position of the checkout. They did at the 
time of the merge - but with the universal truth that functionality 
which is not tested is broken, this condition must have been broken by 
some test cases which were committed since that time (February this year).


The issue is pretty simple to fix up. It is caused by an oddity with 
node module resolution which generally prohibits resolving a module name 
from within itself, unless its parent is named "node_modules". There was 
a lot of code which was a bit slack about this in the old days, for 
example, test code which would issue


require("universal");

from within universal. This is faulty, but still seemed preferable to 
writing what it seems that node authors would have liked, which is 
something uncivilized like


require("../../../../..");

which as well as being incomprehensible will break if the test is moved 
to another directory.


For a while now this has been resolved by the Fluid module system API 
with docs at 
http://docs.fluidproject.org/infusion/development/NodeAPI.html#fluid-require-modulename-foreignrequire-namespace-


by replacing the call above with

require("%universal")

the problem is solved, but it is possible that not everyone got the 
memo. If some tests fail, and we care, we should i) reopen the JIRA 
GPII-2151 with a list of the failing ones and after it is fixed ii) 
change our CI for universal so that it checks it out to an ordinary 
directory.


CHeers,

Antranig

On 03/07/2017 15:50, Tirloni, Giovanni wrote:

Hello,

  Regarding our requirement to have the universal live inside a node_modules 
directory, could someone help me understand the machinery behind that? Since 
some tests pass and others don't (when universal is not living inside 
node_modules), does that mean this is a work in progress?

  I've found this JIRAs that seem to be related but I'm not sure they document 
the situation completely:

https://issues.gpii.net/browse/GPII-23
https://issues.gpii.net/browse/GPII-36
https://issues.gpii.net/browse/GPII-91
https://issues.gpii.net/browse/GPII-492
https://issues.gpii.net/browse/GPII-1527
https://issues.gpii.net/browse/GPII-2151

  I apologize in advanced if someone explained this to me before, my memory is 
a bit blurry on this topic.

Regards,
Giovanni
___
Architecture mailing list
Architecture@lists.gpii.net
http://lists.gpii.net/mailman/listinfo/architecture



___
Architecture mailing list
Architecture@lists.gpii.net
http://lists.gpii.net/mailman/listinfo/architecture

Re: [Architecture] Standardizing environment variable names

[Antranig Basman]

+1 - I further propose we prefix them with GPII_ to make responsible use 
of this OS-wide shared space of names. GPII_PREFERENCES_SERVER_PORT?


This corresponds more closely with our use of global names within 
JavaScript processes.




On 23/05/2017 17:23, Gill, Avtar wrote:

+1 for prefixing deployment-related environment variables with component names.

Avtar


-Original Message-
From: Architecture [mailto:architecture-boun...@lists.gpii.net] On Behalf Of 
Tirloni, Giovanni
Sent: May 17, 2017 7:51 AM
To: architecture@lists.gpii.net Architecture 
Subject: [Architecture] Standardizing environment variable names

Hello,

  With the work being done by Antranig/Tony on new ways to configure components 
through environment variables and files [0][1], it seems important to 
standardize how they are named.

  I would like to propose we prefix the variables with the component's name:

POUCH_MANAGER_
LIFECYCLE_MANAGER_
PREFERENCES_SERVER_
FLAT_MATCHMAKER_
CANOPY_MATCHMAKER_
FLOW_MANAGER_
RAW_PREFERENCES_SERVER
DEVICE_REPORTER_

  So for the Preferences Server, we would have the following environment 
variables:

PREFERENCES_SERVER_PORT = integer
PREFERENCES_SERVER_COUCHDB_URL = string
PREFERENCES_SERVER_LOGGING = boolean

  Similarly for the Flow Manager:

FLOW_MANAGER_PREFERENCES_URL = string
FLOW_MANAGER_MATCHMAKER_URL = string


  Of all the components in GPII, we (DevOps team) have only had the need to 
configure the Preferences Server and the Flow Manager so far, for our 
cloud-based deployments.

  Additionally, the entire flexibility of the config files cannot be expressed through 
environment variables, so the latter would only be used for the most common/used 
configuration settings while leaving the config files for the full "experience" 
of configuring the GPII.

  During the F2F in Toronto we also had questions about if we should have new 
config files dedicated to declaring these env variables, who should own them, 
etc. I'm hoping the env vars prove useful enough for CI and also developers 
that we can embedded them into the most commonly used config files. That would 
enable us to provide Docker containers that would be useful during the 
development workflow too (making it easier for developers to create custom 
scenarios).

  How does everybody feel about this?


1 - https://github.com/fluid-project/kettle/pull/33
2 - https://github.com/the-t-in-rtf/gpii-launcher

Regards,
Giovanni
___
Architecture mailing list
Architecture@lists.gpii.net
http://lists.gpii.net/mailman/listinfo/architecture
___
Architecture mailing list
Architecture@lists.gpii.net
http://lists.gpii.net/mailman/listinfo/architecture



___
Architecture mailing list
Architecture@lists.gpii.net
http://lists.gpii.net/mailman/listinfo/architecture

[Architecture] Feedback on PCP API section 5

[Antranig Basman]

As requested by Javi, here is some feedback on section 5 of our current 
draft PCP API, currently held in the wiki at


https://wiki.gpii.net/w/Personal_Control_Panel_API#The_PCP_API_.28or_messaging_protocol.29


i) We need to explain what protocol this API actually operates over. I 
get the impression that it will take the form of text-encoded JSON 
messages exchanged over WebSockets on some port to localhost, but this 
isn't clear from the description. Even if this isn't the form that we 
finally deploy the PCP in, we need to be clear how this will work during 
tool development, and that this is an insecure encoding of the API that 
will be used during Astea's initial development of the tool. I think 
it's reasonable that we don't couple this work to Steve Grundell's 
ongoing investigations of the best scheme for secure IPC.


ii) The actual content of the payloads is a bit mixed up.
a) There is an "origin" block which I haven't seen before - is this 
related to some other source of information in the system, e.g. the 
solutions registry or matchmaker? How is this expected to be filled in?


b) There is a confusion of containment levels with generic material such 
as dynamic: "false" occurring next to specific material such as 
stepValue: 1 - we should make sure that all this latter material is 
properly nested within a "schema" block of the kind we are sourcing from 
Steve's draft solutions registry/settings payloads of this week.


c) It's not the job of the PCP API to encode a widget type as with 
widget: "slider" - we went through the exercise of ensuring that the 
schematic material we were sending was sufficient to encode this by itself.


d) In general rather than designing the API "as it stands" here, we need 
to link the content of the payload to the content of other payloads as 
they are seen in the GPII - as documented for example here - 
https://github.com/GPII/gpii-payloads - and we should try as hard as 
possible to make sure that this API contains as few elements as possible 
that can't be referred directly to one or other of these payloads.


In particular it looks like most of our payload contents can be sourced 
to some parts of the "megapayload" as it is built up here - 
https://github.com/GPII/gpii-payloads/blob/master/LocalMatchMaker.md


Rather than design special message types such as "changeContext", we 
should instead where possible stream changes to this structure instead. 
You can see these being applied to the session's payload at lines like 
this:

https://github.com/GPII/universal/blob/master/gpii/node_modules/lifecycleManager/src/LifecycleManager.js#L288


Most of the "PCP API" will then just consist of telling users which are 
the changes of interest to them that they can subscribe to. This should 
be done via bus of messages that are identical to the ones in this Nexus 
API:


https://wiki.gpii.net/w/Nexus_API#Remote_API_5
___
Architecture mailing list
Architecture@lists.gpii.net
http://lists.gpii.net/mailman/listinfo/architecture

Re: [Architecture] GPII Windows code linting

[Antranig Basman]

Thanks, Alfredo, that's brilliant, and really helpful!

Cheers,

Antranig

On 16/10/2017 10:24, Alfredo Matas wrote:

Hi all,

I've added a job to the CI task list that runs the "grunt lint" command over the source code as we talked at 
our last Windows meeting.


A sample of the output is

https://ci.gpii.net/job/windows-code-analysis/1/console


--
Alfredo




___
Architecture mailing list
Architecture@lists.gpii.net
https://lists.gpii.net/mailman/listinfo/architecture

[Architecture] Updated, simplified PCP API

[Antranig Basman]

I've updated my pull request at https://github.com/GPII/universal/pull/549 to incorporate a further 
simplified version of the PCP API, which is more closely focused on the needs of the UI. This now encodes 
the model state corresponding to the settings widgets directly rather than this information being 
synthesized from excerpts of payloads taken around the system. I've updated the PCP API "work in progress" 
Google Doc to describe this API at 
https://docs.google.com/document/d/1c7QWlh-CFmkdERja7m0VRby50rySAkAP9eLGNiSlZGE/edit#
There is another example of a test payload showing an update to an application-scoped setting at 
https://github.com/amb26/universal/blob/dcdd43ff551eac2218f8a7552a0a6c3422be7d79/gpii/node_modules/flowManager/test/PCPChannelTests.js#L32
I had a chat with Georgi this morning who confirmed he thought the new API would be easy to work with. I 
will be working this afternoon for architectural support for
https://issues.gpii.net/browse/GPII-2608 - "Select preference sets" which can be done with the current 
architecture.
Support for https://issues.gpii.net/browse/GPII-2607 will continue after Kaspar returns on Monday - this 
requires some further rework of the core architecture to support the flow of updates to settings propagated 
to the running system. Work can progress on this issue in the meantime by means of mocks and tests.


There will be discussions and updates on these and other PCP related issues at the PCP status meeting which 
is upcoming shortly.


Cheers,

Antranig
___
Architecture mailing list
Architecture@lists.gpii.net
https://lists.gpii.net/mailman/listinfo/architecture

[Architecture] GPII electron app merged into master

[Antranig Basman]

Michelle's long-running work in developing the GPII electron app (I'm aware that the term "GPII app" has 
been deprecated for use in the wider community, but I am using the term in a specific technical sense which 
is meaningful to developers) at https://github.com/GPII/gpii-app/pull/17 has been merged into the project's 
master, since it now meets the criteria of our technical governance - it is reasonably stable, 
well-structured work with good test coverage. Congratulations to Michelle for patient, careful work on this 
crucial component of the GPII during this year (originally inherited from a sketch implementation by Steven 
Githens), which is now forming the basis of work on the PCP (now the PSP).


Could all those with active work that depends on this project now please regenerate their pull requests 
against this state of master, which will now form the basis of ongoing work -


Cheers,

Antranig
___
Architecture mailing list
Architecture@lists.gpii.net
https://lists.gpii.net/mailman/listinfo/architecture

[Architecture] OAuth2 Resource Owner Credentials work merged into core

[Antranig Basman]

Continue with our run of integrating major work, I'm pleased to report that Cindy's significant pull request 
https://github.com/GPII/universal/pull/519 for https://issues.gpii.net/browse/GPII-2434 (GPII-2435) has been 
merged into master today. This implements the central engine and OAuth credential type by which a local flow 
manager authenticates itself to the cloud in order to retrieve settings. This is a prerequisite for the "PSP 
with memory" implementation and clears the decks ready for us to begin the work whereby a properly 
authenticated local FlowManager may write preferences back to the cloud on behalf of the PSP, which is our 
next top priority for core architectural work.

Congratulations to Cindy on the many months of work needed for this intricate 
and capable implementation!

Cheers,

Antranig
___
Architecture mailing list
Architecture@lists.gpii.net
https://lists.gpii.net/mailman/listinfo/architecture

[Architecture] Glorious Merge

[Antranig Basman]

I'm very happy to report that Kaspar's branch pull https://github.com/GPII/universal/pull/561 for GPII-2655 
is now gloriously merged, marking the near-endpoint of a long process of normalising our architecture. Most 
crucially this provides core architectural support for Astea's excellent PSP (Personal Settings Panel) UI 
work updating the system settings in a live system, which will enter its first round of usability testing 
next week. This excellent and careful work by Kaspar in particular marks the destruction of our vestigial 
"UserUpdate" endpoint left as a remnant from long-ago work on Cloud4All's then "PCP", which you may see 
deleted in this pull together with its mournful comment "This endpoint does nothing useful in particular and 
has absolutely no useful tests". This marks the near-endpoint of this 4-year arc of development as the GPII 
transitions from an academic research project to a product which may be ready to place in front of real users.


The final stage of architectural normalisation is in progress with Cindy's pull request 563 at 
https://github.com/GPII/universal/pull/563 enabling writing of updated settings back to the user's 
preference safe in the cloud, which is now entering review.


Congratulations all round to the team on their laser-like (in the cliche of the current UK government) focus 
and continued hard work!


Cheers,

Antranig
___
Architecture mailing list
Architecture@lists.gpii.net
https://lists.gpii.net/mailman/listinfo/architecture

[Architecture] Congratulations to Cindy

[Antranig Basman]

Congratulations to Cindy on the merge this evening of her long-term work on the new GPII Data Model 
described by GPII-2630, and the annotated schema written up in the wiki at 
https://wiki.gpii.net/w/Keys,_KeyTokens,_and_Preferences . This represents over 6 months of careful, patient 
and skilled work in adapting our existing architecture to the new use cases characterised in the APCP, and 
is the crucial enabler to getting us up and running with our new cloud-based flow manager and preference 
server meeting the needs of our first deployment with writable preference safes later this year. A hail of 
further merges will now follow across several projects as described in the head writeup at 
https://github.com/GPII/universal/pull/591 - which will provide the basis for the live infrastructure 
supporting these deployments in the cloud.
Cindy's work also considerably rationalises our infrastructure as inherited from the Cloud4All days, 
removing unnecessary implementations, and renaming and realigning our terminology with the new accepted 
naming, e.g. PCP -> PSP, NP sets -> preference sets, userToken -> GPII key, etc.


Many thanks to Cindy for bringing this to a great conclusion as always, and looking forward to the next 
months of work that will be based on this implementation. As usual, anyone who has an active pull request 
against universal will certainly need to update it now as a result of the large number of conflicts that 
will be introduced with respect to this work. Wishing Cindy a great holiday as she is off on Monday!


Cheers,

Antranig.
___
Architecture mailing list
Architecture@lists.gpii.net
https://lists.gpii.net/mailman/listinfo/architecture

[Architecture] Nominating Steve Grundell for commit access

[Antranig Basman]

I would like to nominate Steve Grundell of RtF-I for commit access to the GPII repositories 
(https://github.com/GPII). The procedures and responsibilities for this are listed on this page:

http://wiki.gpii.net/w/GPII_Technical_Governance#Process_for_Granting_Commit_Access

Steve's work over the two years he has been attached to the APCP project has been little short of 
miraculous. Within his first weeks on the job he had resolved a thorny race condition in the Windows 
settings handlers that had foxed the core team for years, and only built from there to tackle seemingly 
impossible problems such as onboarding the mysterious modern accessibility settings found in recent builds 
of Windows 10, and implementing our "Install on Demand" system with about one tenth the engineering effort 
that was originally budgeted.


Steve's work quickly reached the level where his pull requests regularly went through with only minor tweaks 
required. A sample of his major work on a core component, the logging and metrics system which is crucial 
for collecting vital information about user activities during our pilots, and can be seen in the following 
pull request:


https://github.com/GPII/universal/pull/515

As well as this, Steve's laconic pragmatism is a healthy antidote to the excitement which can sometimes 
accompany our technical decision-making process. He can always be depended upon to not only rapidly come up 
with an ideal solution to difficult technical problems, but also demonstrate and communicate a deep 
understanding of the underlying issues. But his work is not only rapid, but careful and thorough. I commend 
him to the community!


Followups set to the closed committer list for voting - an update will be given 
here on the result.

Cheers,
~Kasper
___
Architecture mailing list
Architecture@lists.gpii.net
https://lists.gpii.net/mailman/listinfo/architecture

[Architecture] Congrats and Thanks to Javi

[Antranig Basman]

As his victorious email sent amongst the team last night shows, Javi has been up essentially through the 
whole night labouring to get the first version of the installer ready for testing ahead of our demo later in 
the month. This has been a herculean effort weaving together more than a dozen branches of work in various 
states of readiness and expertly resolving the mismatches and early bugs.
This is a great turning point for the project as we get ready to demonstrate our first cloud-ready builds of 
the system together with its new front end, the "Quick Set Strip". Congrats to Javi on his success and 
thanks for putting in all the late hours - perhaps it will be time for a nap soon :)


Cheers,

Antranig
___
Architecture mailing list
Architecture@lists.gpii.net
https://lists.gpii.net/mailman/listinfo/architecture

[Architecture] Fwd: Re: Discovered another bug

[Antranig Basman]

 Forwarded Message 
Subject:Re: [Architecture] Discovered another bug
Date:   Mon, 16 Jul 2018 00:36:12 -0400
From:   Gregg Vanderheiden GPII 
To: Antranig Basman 
CC: Kavya Komuru , Sandra Ellett-Salmoran 




I was using the Microsoft  build I think
let me check the version number

it was 1.0.0-demo-MS-0.6

thanks - that sounds like a good plan

H 15 seconds eh?     I guess that is to allow for the person to do a save - 
if that pops up.
I wonder for AT though…

Any way that can be programable?   in a demo that is a LONG time.

OR  - if I can set that time for specific applications.


Oh - by the way — the ELAINE also did not disappear on Keyout
I have had that problem a number of times.

I have also gotten a complete black screen sometimes

Ah and the  Large-Dark  SnapSet  now gives me  LARGE and LIGHT    (the high contrast where things are Black 
on White rather than white on black.


So I guess  a lot is not working right now.

But lets see what the next build yields.   ( cc’d  Kavya so she can watch for 
these on the next build)

PS  -   can we put   SVEN ( classic shell etc)  in the main build?

thanks

G

On Jul 15, 2018, at 5:52 PM, Antranig Basman <mailto:antranig.bas...@colorado.edu>> wrote:


Cheers Gregg - I've written up this report as https://issues.gpii.net/browse/GPII-3208 
<https://secure-web.cisco.com/1F1Uev-eacQZXgcBuipljKCHv69vvgWozO6ldFu5BDl5KEZn-B0pVd7PuKz8hvkmqkFEyGpta-6blg7XSDPCD6Q0JmPqkTXaVAjZsSQgYqpAtThJC-u2VE5L16v0vuJFSuarFZIQ5rHW7J3Zf6Szqd_UOQFzeDoAo1Tpd3QWqCk0k7CGTb275eKIuSVINHR2rHj2ipF3rkyDk3y3GCzMQBdwpgd3M3YR4aM6Eavv93up3KRxZGWiZJwY1VSK6bFfCe_EWhRnVS4Wth0VtYj_PdCQjY4JUA4EwrLWKCemMi05VJM7tl2XtBGe_l31n3evD2iAEeM3Ov-OqhYrnLZeYTrvjS2B7GIBA-wSManb2LdYfZ9nU2oQ1SWGuTVlu8mdZioMBMxsdMvwh3x3gTMmZ2ywp-W9ERHuI5OQcOvFp1plNK5nMdv8SMSjiAX6yFJqJknoNRXe0Zxs7rUhkalh1cQ/https%3A%2F%2Fissues.gpii.net%2Fbrowse%2FGPII-3208> 
.
There has been a new behaviour implemented in the system recently (combination of Kaspar's last work and a 
new close handler from Steve Grundell) which is intended to handle this situation robustly. The workflow is -

i) Send the application's window a standard quit message
ii) If it has not responded to this after 15 seconds, kill the application 
forcibly

So we do actually check whether things quit during the 15 second transition between i) and ii), and the 
method used in ii) should work immediately. However we should verify how recently the build you were 
testing was made, and whether it incorporates this behaviour, and if it is indeed sufficiently recently to 
include the new implementation, whether there is some special reason that NVDA might be unkillable in this 
condition.


Cheers,

Antranig

On 15/07/2018 20:28, gregg...@umd.edu <mailto:gregg...@umd.edu> wrote:

Hi All
You may have discovered this already - and if so great.   But I think I discovered this bug during my 
plenary presentation today.
After pre-testing the auto-personalization a dozen times without problem -  when I key’ed into NVDA on 
stage - it decided there was an update.   When I tried to key out  — it keyed out but NVDA kept running 
 and talking.
Evidently it doesn't quit when asked if it has an update dialog open.    I presume that GPII doesn't yet 
check to see if things quit  (does it?   will it?)
Once it doesn't quit — you can’t use GPII to turn it off of course - because it is running when you key 
in— so it will be running after you key out  (I presume)

At any rate it ran for the rest of the keynote  (I muted it after I thought of 
it).
Is this something that is on the docket to get fixed?
thanks
Gregg
___
Architecture mailing list
Architecture@lists.gpii.net <mailto:Architecture@lists.gpii.net>
https://secure-web.cisco.com/14Z5rHZLMh8vTqJsJhZgazw6YHIqvBPk4BLlEj7p5nsEJ0gXeXNfZIOCMa_fQTT07tdqyASBhky6104ErdZs9p5IJukQjaWskhg_Bb6cB4Rr0Wrl6pei60J5usBhNRNZPOrA-4_FsTbpIRdZU6GSW9u-VD1Da9XrpcngeLYjO-BDGH1ncYXBXa8Pru3kw7A60hCvXgmGyDV7IJOyQlpj5A2nFIcsFunlH3LlBvWqiN6RgI0VwPaVZSRyk9-ZZe5UsSIAuu9hqq0p8idB9vvuGMZAQjabBAY5bS2A5WBth8CM-exDSaLY-yfUoKxe0vgM-rU69zjWw76X1pW69tP9jdJx8Qkg-VFBesN6EbaNyIkjInjUbT-AP7pe9bFgKl4rZX_WrHj5kGNhTB39LO9dLQ8S1Av3DJWKSoODgux9ikzjGp9xPebvbKdhzYEsJ3r83_vziaXSPUY583IPYpeUwfQ/https%3A%2F%2Flists.gpii.net%2Fmailman%2Flistinfo%2Farchitecture


___
Architecture mailing list
Architecture@lists.gpii.net <mailto:Architecture@lists.gpii.net>
https://lists.gpii.net/mailman/listinfo/architecture


___
Architecture mailing list
Architecture@lists.gpii.net
https://lists.gpii.net/mailman/listinfo/architecture

Re: [Architecture] Discovered another bug

[Antranig Basman]

Cheers Gregg - I've written up this report as 
https://issues.gpii.net/browse/GPII-3208 .
There has been a new behaviour implemented in the system recently (combination of Kaspar's last work and a 
new close handler from Steve Grundell) which is intended to handle this situation robustly. The workflow is -

i) Send the application's window a standard quit message
ii) If it has not responded to this after 15 seconds, kill the application 
forcibly

So we do actually check whether things quit during the 15 second transition between i) and ii), and the 
method used in ii) should work immediately. However we should verify how recently the build you were testing 
was made, and whether it incorporates this behaviour, and if it is indeed sufficiently recently to include 
the new implementation, whether there is some special reason that NVDA might be unkillable in this condition.


Cheers,

Antranig

On 15/07/2018 20:28, gregg...@umd.edu wrote:

Hi All

You may have discovered this already - and if so great.   But I think I 
discovered this bug during my plenary presentation today.

After pre-testing the auto-personalization a dozen times without problem -  
when I key’ed into NVDA on stage - it decided there was an update.   When I 
tried to key out  — it keyed out but NVDA kept running  and talking.

Evidently it doesn't quit when asked if it has an update dialog open.I 
presume that GPII doesn't yet check to see if things quit  (does it?   will it?)

Once it doesn't quit — you can’t use GPII to turn it off of course - because it 
is running when you key in— so it will be running after you key out  (I presume)

At any rate it ran for the rest of the keynote  (I muted it after I thought of 
it).

Is this something that is on the docket to get fixed?

thanks

Gregg


___
Architecture mailing list
Architecture@lists.gpii.net
https://secure-web.cisco.com/14Z5rHZLMh8vTqJsJhZgazw6YHIqvBPk4BLlEj7p5nsEJ0gXeXNfZIOCMa_fQTT07tdqyASBhky6104ErdZs9p5IJukQjaWskhg_Bb6cB4Rr0Wrl6pei60J5usBhNRNZPOrA-4_FsTbpIRdZU6GSW9u-VD1Da9XrpcngeLYjO-BDGH1ncYXBXa8Pru3kw7A60hCvXgmGyDV7IJOyQlpj5A2nFIcsFunlH3LlBvWqiN6RgI0VwPaVZSRyk9-ZZe5UsSIAuu9hqq0p8idB9vvuGMZAQjabBAY5bS2A5WBth8CM-exDSaLY-yfUoKxe0vgM-rU69zjWw76X1pW69tP9jdJx8Qkg-VFBesN6EbaNyIkjInjUbT-AP7pe9bFgKl4rZX_WrHj5kGNhTB39LO9dLQ8S1Av3DJWKSoODgux9ikzjGp9xPebvbKdhzYEsJ3r83_vziaXSPUY583IPYpeUwfQ/https%3A%2F%2Flists.gpii.net%2Fmailman%2Flistinfo%2Farchitecture



___
Architecture mailing list
Architecture@lists.gpii.net
https://lists.gpii.net/mailman/listinfo/architecture

[Architecture] Vindication of our policy for exact dependency versions

[Antranig Basman]

Our project policy has for some time been to only permit exact versions to appear in project dependencies 
listed in package.json - this is at odds with most industry recommendations, and also the action of several 
automated tools, to allow open semver ranges of the form "~3.7.1".
As it turns out, yesterday a virus was distributed exploiting exactly this facility - written up at 
https://github.com/eslint/eslint-scope/issues/39 , this involved compromise of the npm credentials of the 
maintainer of a widely used package for linting to upload a corrupt version to the package registry with 
only a minor version update. This is not a package that we used, but it is one that we might have used quite 
easily, and had our policy not been in place we would have been exposed to the exploit (which in this case 
was a rather clumsy and harmless one, but you never know).


Our code review policies ensure that only fixed versions of the form "3.7.1" appear in our dependencies, so 
do be vigilant to ensure any ranges don't slip through. Note that problems of this kind could affect 
non-runtime dependencies such as devDependencies used for linting tasks of this kind.


Cheers,

Antranig.
___
Architecture mailing list
Architecture@lists.gpii.net
https://lists.gpii.net/mailman/listinfo/architecture

[Architecture] Another Glorious Merge

[Antranig Basman]

Dear All -
  This is to report another important milestone in improving our quality infrastructure. This evening 
another significant branch has been merged, itself representing more than 6 months work by Tony Atkins but 
building on yet more work implementing similar capabilities for Infusion and captured in other projects in 
our ecosystem, including gpii-testem. As a result of this, we will now have complete code coverage 
information pooled between our web-based and node-based unit tests and integration tests, which will greatly 
improve the efficiency of future code review.


The code coverage reports can be browsed within the "reports" directory created after a standard 
(successful) run of the "npm test" task. We should be aiming to reach a baseline quality target of around 
90% branch coverage, which across most of our implementation we do already. Once we reach this uniformly, we 
should consider how further engineering cycles should best be spent.


Similar capabilities will now be rolled out across our other GPII projects, and also we will probably try to 
enroll in some form of coverage dashboard so that this can be checked in an automated way as part of our CI.


Could everyone who has outstanding pull requests against universal please merge them up against current 
master, and if your work has contributed any further implementation files you will need to explicitly list 
them against the peculiar patterns found in the .nycrc file listed here (bug has been filed in the upstream 
"istanbul" project which will hopefully make this unnecessary one day):


https://github.com/GPII/universal/blob/master/.nycrc

This has been a long road with many awkward turnings due to mismatched assumptions and inflexible 
implementations in the tower of projects that we depend on, and let us all join in congratulating Tony on 
the endurance and carefulness needed to land this highly valuable work improving our project infrastructure.


Cheers,

Antranig.
___
Architecture mailing list
Architecture@lists.gpii.net
https://lists.gpii.net/mailman/listinfo/architecture

Re: [Architecture] Proposal for using JSON schemas in combination with i18n message keys...

[Antranig Basman]

Thanks for putting this together, I will spend some time reading it. Unfortunately I won't be able to make 
our slot tomorrow but we could add it as an agenda item at Arch or have a smaller scope meeting later in the 
week -


Cheers,

Antranig

On 26/03/2018 15:59, Tony Atkins wrote:

Hi, All:

Tomorrow morning we have the latest in our series of meetings to try to find a way to use JSON Schemas for 
both validation and UI errors, and to do so in a way that allows us to continue internationalising the 
output presented to users.


As this is a fairly in depth topic, I have prepared a draft proposal with a 
number of examples:

http://the-t-in-rtf.github.io/drafts/infusion-and-json-schema-feedback-two.html

I would like to go through this together tomorrow, I'm sending it around now for those who would like to 
review ahead of time.


Cheers,


Tony


___
Architecture mailing list
Architecture@lists.gpii.net
https://secure-web.cisco.com/1zd3BtV1HF5MiCKoqmTbQHBOyyhMliyxgEakCthAP73MUlwqi4AEaIeFpvtNaxrPe-d1doQwxP9F42eRCRRRtqmqTM6G-SQmef5Ax_XwoAgzSrZkGxz1pLR49EQ3huz7p0ZN2JTwrYCCq9yxXLT1VGJtL241D1bNohAyRUUPZ8HKVI1yitgKehUqbsIENmldEMlN1SvbnOtABIdPTKn-xv2r8FyeIBzpK3ZDai0OFPyP8_4pQHXEXt-cmZ4KyCtBWHP-gZcSfskHCvm_d7VM6gApoNcG0o5D0QT1mXfnBT8VD9aXvMa6ehl21AMtIP7Gt7ETWom2WJiH-FCHnaCLjqG7BXto1sGhcgiT3APXmZUSEb033VIahBUCPNVgX4gihf13XHuI9LNjyAfp_lt_zTSjKp21y3T3rbqkFjgOdToO8WdSa8C0HtiQaZkHIkc4VWSwR5mAdNYtTyZ4ChZ8dqg/https%3A%2F%2Flists.gpii.net%2Fmailman%2Flistinfo%2Farchitecture



___
Architecture mailing list
Architecture@lists.gpii.net
https://lists.gpii.net/mailman/listinfo/architecture

[Architecture] Hats off to Hadtkins

[Antranig Basman]

Hi all - I'm happy to announce the merge earlier today of a huge amount of work by Tony Atkins in rewriting 
all of our core test cases away from PouchDB, a popular in-process replica of CouchDB, in favour of 
executing against an actual CouchDB instance, running in either a docker or vagrant container. This work was 
issued in pull request https://github.com/GPII/universal/pull/728 written up in 
https://issues.gpii.net/browse/GPII-3619 .


The original thinking behind our adoption of PouchDB was to isolate our test runs against dependence on 
external resources, as well as promising better between-test isolation based on the ability to bring up a 
fresh database each time. In practice, we increasingly found PouchDB a source of problematic memory leaks as 
well as odd incompatibilities with CouchDB itself which diminished the value of using it as a mock in the 
first place.


Eventually things came to a head with https://issues.gpii.net/browse/GPII-3630 where the addition of a 
moderate-sized onboarding pull from Tony himself tipped the test process over the edge into consuming a full 
2GB process size, meaning that we could no longer guarantee to reliably run tests on future onboarding pulls 
at all. Since we originally adopted PouchDB, improvements in the convenience and reliability of container 
technologies orchestrated in CI have improved significantly, as well as the reliability of out-of-process 
debugging tools which can now be used as a comparable replacement to in-browser debugging.


Tony's replacement with CouchDB drops the memory usage of the test run by around a factor of ten, and in CI 
at least runs comparably quickly to the PouchDB version, even taking in to account the overhead in 
instructing CouchDB to drop and reconstruct the database between test runs. He has worked industriously and 
meticulously in rewriting thousands of our core test cases, as well as in many instances improving their 
structure by adopting Infusion's newer "sequence grade" approach for orchestrating asynchronous tests.


This places us in a great position to be more agile in the face of an ever-increasing stream of onboarding 
work by JJ, Tony and others, as well as ensuring that we go into our upcoming deployments at NOVA and 
elsewhere with greater confidence in the output of our CI. Thanks to him for this amazing work, done very 
quickly and to a high standard under time pressure - a bottle of the very finest Scotch has been sent his 
way across the remainingly integral parts of the EU.


Cheers,

Antranig.
___
Architecture mailing list
Architecture@lists.gpii.net
https://lists.gpii.net/mailman/listinfo/architecture

[Architecture] Run One Thousand

[Antranig Basman]

I'm pleased to report that after a long run of failures, runs #999 and #1000 on gpii-app have been 
successful, after we were able to combine fixes from Javi, Cindy and Grudell to unblock on the several 
correlated failures that were causing APIs to mismatch and builds to fail.


https://ci.gpii.net/job/gpii-app-test/

Could everyone who has outstanding pull requests on gpii-app please update them with master and see what 
genuine failures remain.


Please note that master of gpii-universal is still considerably behind that of gpii-windows and not 
compatible with it, as a result of further fixes required by Adtkins' schema validation work - we will start 
addressing these tomorrow and probably partially back out some of this work in order to restore consistency.


Cheers,

Antranig
___
Architecture mailing list
Architecture@lists.gpii.net
https://lists.gpii.net/mailman/listinfo/architecture

[Architecture] Nominating Tony Atkins and Joseph Scheuhammer for commit access

[Antranig Basman]

Indeed, perfection is achieved on the point of collapse.

I would like to nominate Tony Atkins and Joseph Scheuhammer for commit access to the GPII repositories 
(https://github.com/GPII). The procedures and responsibilities for this are listed on this page:

http://wiki.gpii.net/w/GPII_Technical_Governance#Process_for_Granting_Commit_Access

Both have demonstrated a sound knowledge of the GPII's working practices and architecture. Tony has been responsible for 
several updates to the core workflow for validating preferences and settings as they sit on disk and are written to the 
cloud, as well as the heroic rewrite of all of our test cases as we moved away from the unstable PouchDB and towards 
testing against a live CouchDB Docker image. Joseph has been responsible for several core components of the GPII 
including the the device reporter and the process reporter, as well as rewriting our production configuration tests.


I commend both of them to the community -

Followups set to the closed committer list for voting - an update will be given 
here on the result.

Cheers,

Antranig

___
Architecture mailing list
Architecture@lists.gpii.net
https://lists.gpii.net/mailman/listinfo/architecture