See email thread below for details.
Make getKeywords, getKeywordValues, and getFunctionalEquivalent
API should reflect service registration.
In other words, the service framework should be a complete layer
between public external API and the resource bundle component.
Doug Felt/Cupertino/IBM wrote on 05/04/2004 10:34:10 AM:
Sounds good to me.
Service registration is a seldom-used feature, and I think it should
be a separate layer on top of the resource bundle code. Let's keep
these things separate, they're easier to deal with that way.
Alan S Liu
05/04/2004 09:33 AM
To: Steven R Loomis/Cupertino/IBM@IBMUS
cc: Doug Felt/Cupertino/IBM@IBMUS, Mark Davis/Cupertino/IBM@IBMUS
Subject: Re: getKeywordValues / getFunctionalEquivalent
I suggest we talk about this (briefly) in person Wednesday, and I'll
personally defer any action on the code.
What might be reasonable is to have two phases:
3.0: getAvailable reflects service registration
3.0: registration does not recognize RFC3066 locales, nor keywords
3.0: getKeywords / getKeywordValues do not reflect registration
3.2: registration possible using RFC3066 locales
3.2: registration possible using keywords
3.2: getKeywords reflects registered keywords
3.2: getKeywordValues reflects registered keyword values
Using a low-level call back to have resource bundle access the
service map seems like it would be desirable if we were to integrate
the service code with the resource bundle code so they were
logically unified (from an API viewpoint). This could work but it
seems a little forbidding. I might prefer layering.
Resource bundle layer: Provides all API ignoring registration.
Services layer: Allows dynamic overlay on top of the locale tree,
and provides identical API that reflects this.
[S Liu/San Jose/IBM@IBMUS; firstname.lastname@example.org;; IBM
Globalization; 5600 Cottle Road; San Jose, CA 95193;; (408) 256-3155|Alan]
Steven R Loomis/Cupertino/IBM
05/03/2004 05:06 PM
Alan S Liu/San Jose/IBM@IBMUS
Re: getKeywordValues / getFunctionalEquivalent
I think you are right. Perhaps what we need to do is build up a
lazy-evaluated persistent map .. maybe the low level functions need
to have call-backs which can access the service's map.
IBM San José Globalization Center of Competency * ICU Team
http://oss.software.ibm.com/icu/ +1 (408) 256-3107
Within IBM:http://icu.sanjose.ibm.com/ 276-3107
5600 Cottle Road - M/2 50-2/B11 San José, CA 95193 USA
Alan S Liu/San Jose/IBM wrote on 05/03/2004 02:51:58 PM:
> Doug & Steven:
> I just had a disturbing thought about the getKeywordValues API,
> getFunctionalEquivalent API, and service registration.
> Is it the case that:
> 1. Someone could register something using a keyword locale, as in:
> 2. And if this happened, should getKeywordValues reflect the new
> custom keyword (in this example, "alan")?
> 3. And likewise for getFunctionalEquivalent, once someone registers
> this, doesn't the functional equivalency map change? So that, for
> instance, if something is registered against any locale, then that
> locale must be regarded as functionally equivalent to nothing else.
> Does this sound correct?
> If so, I have more work than I thought...
> A. The Java service code needs to be extended to handle ULocales as
> well as Locales.
> B. The service code on both C++/Java needs to be wired up to handle
> the above logic.
> [S Liu/San Jose/IBM@IBMUS; email@example.com;; IBM
> Globalization; 5600 Cottle Road; San Jose, CA 95193;; (408) 256-3155|Alan]