On Thu, Sep 3, 2015 at 5:24 PM, Mark Finkle <[email protected]> wrote:
> On Thu, Sep 3, 2015 at 4:11 PM, Martin Thomson <[email protected]> wrote: > > > On Thu, Sep 3, 2015 at 12:21 PM, Mark Finkle <[email protected]> > wrote: > > > We only intend to use this when the experiment is in a code path that > > > happens very early in application startup. We lose all ability to > > > dynamically alter the configuration and code path if we use this > > approach. > > > Any changes must be landed in the client application. > > > > > > I'm not sure that I understand your concern here. If you were to > > publish the low and high values for a given experiment, then you do > > commit to using CRC32 (and low and high markers), but that's not a > > problem in an of itself. After all, you could include an indicator > > that describes how the buckets are calculated if you wanted to allow > > for some flexibility. > > > > If the concern is that you won't be able to update rapidly, I'd > > suggest that you might want to look at pushing updates rather than > > rely on clients polling. > > > > Pushing updates is exactly what we want to avoid. Pushing updates is what > we do right now, and it's not without issues. Pushing updates also makes it > almost impossible to mange staged rollouts, or quick backouts. Going faster > is part of our goals too. I'm not following the concern. The usual way to do this is to have the server publish a manifest that tells the client "if you are in this range of the UUID space, then behave this way". You then use exactly the same retrieval policies you currently do but instead of publishing per-client instructions, you publish the manifest. -Ekr
_______________________________________________ mobile-firefox-dev mailing list [email protected] https://mail.mozilla.org/listinfo/mobile-firefox-dev
