Speaking at a very high level: so long as you version the protocol, version the data format, and strongly define the types in the format (none of the "sometimes a number, sometimes a number as a string" crap we have in Sync), I'm happy.
Remember that users don't upgrade clients as often as we'd like, so we need to be able to meaningfully lock them out, keep talking their language, or negotiate a format. I don't recommend shipping *anything* without first having versioning; you can always declare a prerelease cutoff point later, but you can only do so if you can identify versions! (Principles: https://old.etherpad-mozilla.org/service-principles ) It's also worth thinking about whether it's easier to just use protobufs or whatever the new hotness is, rather than going to the effort to fit strict formatting on top of JSON. If this gets wide adoption, you might regret using JSON. On Thu, Apr 28, 2016 at 12:13 AM, Mark Hammond <[email protected]> wrote: > 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 >
_______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
