This was cross-posted with [email protected] I have answered there. Let's continue the thread there
Thanks Le 15/07/14 16:44, [email protected] a écrit : > 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 > _______________________________________________ > 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
