Hey folks, It seems we (server and client side people) have different expectations as to what the server should offer in terms of backwards compatibility, and I believe we need to solve that ASAP to avoid extra confusion in the future.
To me, there is almost no need to support users that are tracking nightly, and that's okay to let their client in a broken state. After all, that's nightly, and that's meant to break. Of course, when possible we should make things use a smooth track whenever possible, but I believe that shouldn't be a requirement. Especially, 0.9 (which is MVP) breaks how you should authenticate due to a server bug that was letting all clients authenticate without really checking everything. Similarly, we filled a bunch of bugs to keep everything consistent, but I believe we probably shouldn't do that. Also, old format call urls aren't supported anymore in the new 0.9.0 release, because that would add some more logic to the server without any real benefit for now. Instead, having a procedure to reset everything on the client and get a new hawk session etc. should IMO be the way to go. We should document that on a wiki page and direct our users to this page, or even have a "reset authentication" button in a Troubleshoot section of the panel settings, to use whenever it's needed for now. Rationale behind this is that I prefer to have a clean API which doesn't start to clutter before we hit MVP. I'm pretty sure we'll have to do that after we land the first version, so we better keep the changes for after :). Of course, it doesn't mean we should try to break everything as soon as we can, but having a calendar of regressions could probably just be enough. Also, as we don't have (yet) any client functional tests, there is no way for us (or you) to catch API regressions in an easy way. That's something being planned with Anthony Hughues with Tarek/Maire help I think. I'm actually very excited that we can have this discussion: it means that we have something moving as fast as we can, and that we're making it a reality :-) — Alexis _______________________________________________ loop-services-dev mailing list [email protected] https://mail.mozilla.org/listinfo/loop-services-dev _______________________________________________ dev-media mailing list [email protected] https://lists.mozilla.org/listinfo/dev-media
