How does the client hook a data provider to a formatter API?

[sffc]

Should the data provider be a global setting, or a required parameter to the formatter, or a combination of both?

[sffc]

We could use a factory model.

struct NumberFormatFactory<'a> {
    pub data_provider: &'a dyn DataProvider,
}

impl NumberFormatFactory {
    pub fn create(&self, locale: &Locale, options: &NumberFormatOptions) {
        NumberFormat::try_new(locale, self.data_provider, options);
    }
}

An advantage is that each type could have its own data provider trait that could be backed by something other than the stock ICU data provider. For example, PluralRulesFactory could be constructed from either a stock data provider or a custom data provider that provides pre-compiled functions.

[nciric]

If I follow your example (pardon my syntax):

# Covers locales from [aa - de)
static_provider = NumberFormatFactory.data_provider = StaticProvider(static_code);

# Covers locales from [de - ..)
dynamic_provider = NumberFormatFactory.data_provider = DynamicProvider(url_to_fetch_data_from);

How would end developer know which one to use, given the users locale? Do we need a layer over this that would do language matching and picking the correct factory?

[echeran]

Is this question about the ergonomic API (seeing as that's what the user would be using directly more often)? IIRC, did we already discuss and agree that the low-level/logical API would always have the data provider be an argument?

Even in the ergonomic API, I think we should always allow the data provider to be an argument, to always expose flexibility/simplicity to the user. I would be against the option of only exposing them via a global setting -- I think this creates complexity that causes inflexibility. I've experienced this type of complexity with Okapi, which comes with pre-made file format handlers and allows you to create and use your own handlers, but it stores all handlers in handler registries (which can be global and/or local), and becomes more complicated when you have multiple implementations of handlers for a single file format, and then those implementations have multiple versions of themselves.

[sffc]

If I follow your example (pardon my syntax):

# Covers locales from [aa - de)
static_provider = NumberFormatFactory.data_provider = StaticProvider(static_code);

# Covers locales from [de - ..)
dynamic_provider = NumberFormatFactory.data_provider = DynamicProvider(url_to_fetch_data_from);

How would end developer know which one to use, given the users locale? Do we need a layer over this that would do language matching and picking the correct factory?

The idea is that you would implement another data provider that wraps the two.

struct MixedProvider(StaticProvider, DynamicProvider);
impl DataProvider for MixedProvider {
  fn load(&self, req: Request) -> Result<Response, Error> {
    if (req.locale < "de") {  // (not a real comparison)
      return self.0.load(req);
    } else {
      return self.1.load(req);
    }
  }
}

Then, the MixedProvider becomes the one that you give to the ICU4X APIs.

Is this question about the ergonomic API (seeing as that's what the user would be using directly more often)?

Yes; this is about the ergonomic layer, and it relates to every ergonomic API implementation, not only Rust but the ones in every other language we choose to target.

IIRC, did we already discuss and agree that the low-level/logical API would always have the data provider be an argument?

Yes, sort-of. The data should be pulled out of the data provider before passing it as an argument to the logical API.

[sffc]

Conclusion from 2020-07-16: Make the data provider an argument in the constructor for now. Later, look if there are ways to add factories or macros to help.

[sffc]

CC @markusicu @macchiati