On 29/04/2016 2:22 AM, Richard Newman wrote: Thanks for the reply!
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!
Yeah, agreed - the schema and payload should be versioned in a sane way, and I think JSONSchema gives us a "good enough" fit here.
(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.
I doubt it's *easier* to use protobufs - JS support is relatively new and requires a new build step - and I haven't considered what changes the server will need and what the team looking after it would think about them. I don't think our payloads will be either large, complex of dynamic enough to make that worthwhile - I think JSON is fine for our needs and sticking with the same basic scheme used by Telemetry (which arguably would be a better fit for protobufs) is valuable.
I'm not sure what other cool-kid-things exist in this space, and maybe I'm just being short-sighted, but this seems like a large yak and I doubt we want push payloads to wait for someone with a large enough razor.
Thoughts? Mark _______________________________________________ Sync-dev mailing list [email protected] https://mail.mozilla.org/listinfo/sync-dev
