We're updating the issue view to help you get more done. 

Services & getKeywords, getKeywordValues, and getFunctionalEquivalent

Description

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:

Alan:

 

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.

 

Doug

 

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; alanliu@us.ibm.com;; IBM

Globalization; 5600 Cottle Road; San Jose, CA 95193;; (408) 256-3155|Alan]

 

Steven R Loomis/Cupertino/IBM

05/03/2004 05:06 PM

 

To

 

Alan S Liu/San Jose/IBM@IBMUS

 

cc

 

Doug Felt/Cupertino/IBM@IBMUS

 

Subject

 

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:

> en@collation=alan

> 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; alanliu@us.ibm.com;; IBM

> Globalization; 5600 Cottle Road; San Jose, CA 95193;; (408) 256-3155|Alan]

Environment

Status

Assignee

Douglas Felt

Reporter

TracBot

Labels

Time Needed

Weeks

tracCreated

May 06, 2004, 12:19 AM

tracOwner

doug

tracProject

ICU4C and ICU4J

tracReporter

Alan Liu <alanliu@9cba6cf8ad53a085

tracStatus

accepted

tracWeeks

1.5

Components

Priority

minor