<html>
<head>
<meta content="text/html; charset=windows-1252"
http-equiv="Content-Type">
</head>
<body bgcolor="#FFFFFF" text="#000000">
Hi all,<br>
<br>
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.)<br>
<br>
IMHO, It is very sound to have a way to validate on both side that
the communication channel meet the protocol requirements.<br>
<br>
Also this asks the question of handling the validation schema
upgrade.<br>
<br>
<ul>
<li>Is the JSON-Schema used for tests only or also embedded in the
client?</li>
<li>Does the JSON-Schema allows additionnal parameters or is it a
strict checking?</li>
<li>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)?</li>
<li>Should we make sure that future upgrade of the schema will
continue to be backward compatible?</li>
<li>What do we do when the data is invalid? Do we reject the
notification? Do we accept it nevertheless?<br>
</li>
</ul>
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)<br>
<br>
Regards,<br>
<br>
Rémy<br>
<br>
<div class="moz-cite-prefix">Le 28/04/2016 09:13, Mark Hammond a
écrit :<br>
</div>
<blockquote
cite="mid:9ae4dcd9-1206-143f-6a50-652c6e92019f@mozilla.com"
type="cite">Hi all,
<br>
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.
<br>
<br>
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.
<br>
<br>
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:
<br>
<br>
* 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.
<br>
<br>
* 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.
<br>
<br>
* All data can be validated without knowing the contents of the
message.
<br>
<br>
* All messages are likely to be somewhat consistent, given someone
will need to define the schema and will use as reference other
existing schemas.
<br>
<br>
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.
<br>
<br>
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?
<br>
<br>
Cheers,
<br>
<br>
Mark
<br>
_______________________________________________
<br>
Dev-fxacct mailing list
<br>
<a class="moz-txt-link-abbreviated" href="mailto:Dev-fxacct@mozilla.org">Dev-fxacct@mozilla.org</a>
<br>
<a class="moz-txt-link-freetext" href="https://mail.mozilla.org/listinfo/dev-fxacct">https://mail.mozilla.org/listinfo/dev-fxacct</a>
<br>
</blockquote>
<br>
</body>
</html>