On 28/04/2016 6:03 PM, Rémy Hubscher wrote:
Hi all,
For the AMO blocklist project, we are working on in the storage team, we
are using JSON Schema validation to make sure clients and servers are on
the same page (the administration panel, the gecko client and the
importation/exportation scripts as well as the storage layer.)
Yeah, that's basically my exact motivation.
* Is the JSON-Schema used for tests only or also embedded in the client?
I think that's similar to what Phil mentioned. IMO I think a production
environment is where this would be used - eg, staging/nightly type
environments *might* optionally do more, but I don't see value in much
more than that.
* Does the JSON-Schema allows additionnal parameters or is it a strict
checking?
IIUC, that's really up to the schema definition so would become an
ongoing discussion - we can make it as strict or as liberal as we choose.
* If we are to ship the JSON-Schema in production code (i.e Firefox)
do we need the ability to upgrade the schema (and the code related
to the usage of the data)?
I don't think we should ship it in production code, but the same
questions remain in terms of where the "canonical" version of the schema
lives and how updates are managed.
* Should we make sure that future upgrade of the schema will continue
to be backward compatible?
In general we must, as we can't change already released clients.
* What do we do when the data is invalid? Do we reject the
notification? Do we accept it nevertheless?
In general I don't think we should validate at runtime.
But yeah, on reflection, without *some* validation it's all just
hot-air, so for this proposal to be taken seriously, it does require
*some* commitment to performing validation in both browser and server
tests sooner rather than later.
Mark
IMHO, It is very sound to have a way to validate on both side that the
communication channel meet the protocol requirements and it worth it
even if it is only for tests (functional/unit tests)
Regards,
Rémy
Le 28/04/2016 09:13, Mark Hammond a écrit :
Hi all,
Edouard has been working on adding payloads to our push messages and
we were having a bit of a discussion about how to define these
payloads. This is becoming relevant to FxA and to Sync, hence I'm
copying both lists.
When defining the data in a payload for a certain message, both the
server and the client must agree on the format. Initially we can
manage this in an ad-hoc basis, but I'm not sure this scales
particularly well.
Somewhat inspired by the new telemetry data pipeline, I'm wondering if
we should consider moving towards using JSONSchema (json-schema.org)
to define our payloads? The benefits I see here are:
* A single format that the client and server can use to describe and
agree on the data being exchanged. We'd need to agree on a canonical
location for a single schema that the client and server agree on, but
that's probably doable.
* Eventually unit tests on both the client and server could use this
schema to validate the messages they send (or expect to receive). This
would also be useful when mocking - eg, unit tests in the browser
could confirm that the mocked data (ie, data we pretend came from the
server) also conforms to the schema, to help validate that we are
indeed testing data that looks like what the server actually sends.
* All data can be validated without knowing the contents of the message.
* All messages are likely to be somewhat consistent, given someone
will need to define the schema and will use as reference other
existing schemas.
This is somewhat aspirational (ie, I'm not suggesting we would do all
that work up-front), but there's already a bug on file to perform
client-side schema validations for telemetry (bug 1249925) and we
could possibly piggy-back off that work for the client side.
Does anyone think this is worthwhile, or am I over-thinking the
problem at hand and ad-hoc management of the payload definitions is OK?
Cheers,
Mark
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct
_______________________________________________
Dev-fxacct mailing list
[email protected]
https://mail.mozilla.org/listinfo/dev-fxacct
_______________________________________________
Sync-dev mailing list
[email protected]
https://mail.mozilla.org/listinfo/sync-dev
