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.)
IMHO, It is very sound to have a way to validate on both side that the
communication channel meet the protocol requirements.
Also this asks the question of handling the validation schema upgrade.
* Is the JSON-Schema used for tests only or also embedded in the client?
* Does the JSON-Schema allows additionnal parameters or is it a strict
checking?
* 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)?
* Should we make sure that future upgrade of the schema will continue
to be backward compatible?
* What do we do when the data is invalid? Do we reject the
notification? Do we accept it nevertheless?
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
signature.asc
Description: OpenPGP digital signature
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
