Hi Antranig, thanks for your detailed feedback :)
On Mon, Jun 5, 2017 at 7:04 PM, Antranig Basman < [email protected]> wrote: > 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_A > PI_.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. > Right, and this is already described in this section https://wiki.gpii.net/ w/Personal_Control_Panel_API#The_API_and_the_communication_channel Let me know if you want me to elaborate this a little bit more. > > 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? With "origin" I meant "solution", horrible name - and yes, this information should come from the solutions registry. > 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. Right, it's been a long time since I last updated the wiki page so I have updated it based on our latest decisions during our pcp api meetings. > > 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 Yes, in fact most of the material is coming either from the matchmaker output or the solutions registry. It's more clear in the wiki page now, but I'll add references to the relevant portions of such payloads. > > > 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_modu > les/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 Agree, I've been working on this direction and I've updated the wiki page according to this approach, let me know how it looks now to you. Also, if you prefer, we can have a short call so I can present the last updates on the API. Again, thanks for taking your time to review this, it really helps a lot. Cheers, Javi > > _______________________________________________ > Architecture mailing list > [email protected] > http://lists.gpii.net/mailman/listinfo/architecture >
_______________________________________________ Architecture mailing list [email protected] http://lists.gpii.net/mailman/listinfo/architecture
