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
