Re: [icu-design] proposal for Code Page detection for ICU4C

[Badi K. S <ba...@ya...>]

Thanks for the response Andy. Yes it makes sense to keep the API as it
is given that data for charset detection will eventually move into the
ICU data files.

Another query about this one:

U_DRAFT  int32_t U_EXPORT2
ucsdet_getUChars(const UCharsetMatch *csm,
                 UChar *buf, int32_t cap, UErrorCode *status);

Don't you think this API should take the open UCharsetDetector object
too since it owns the input text?

Badi

On Fri, Oct 07, 2005 at 01:50:37PM -0700, Andy Heninger wrote:
>On 10/5/05, Badi Kumar S <ba...@ya...> wrote:
>>
>> I had a question about this API:
>>
>> ucsdet_getDetectableCharsetsCount(const UCharsetDetector *csd, UErrorCode *status);
>>
>> If we are implementing the Recognizers that the detector service uses,
>> as a static array of some sort, it would insure that this data would be
>> initialized before the library is loaded. Hence, I think we don't have
>> to force the user to supply a valid, open charset detector as the first
>> parameter to this function.
>
>I don't think that relying on static data will work out.  The data for
>charset detection will eventually move into the ICU data file
>(alongside charset conversion data, collation data, property data and
>everything else).   It would nice to force the loading to only happen
>on open() operations, and not as a side effect of other functions.
>
>Another choice would be for getDetectableCharsetsCount() to force the
>data to load behind the scenes if it wasn't already loaded.  Checking
>(safely) whether a load is needed requires thread synchronization, but
>getDetectableCharsetsCount() probably isn't particularly performance
>sensitive, so the cost of mutexing it shouldn't be an issue.
>
>>  I'm suggesting removing the first parameter.
>
>I'm not sure which way is best.  Requiring the parameter cleanly
>sidesteps all possible initialization problems.  On the other hand,
>the parameter is logically unnecessary, and it seems like
>implementation considerations may be having undue influence on the
>API.
>
>Let's see what everyone else thinks.
>
>-- Andy
>

-- 
Anyone can do any amount of work provided it isn't the work he is
supposed to be doing at the moment.
		-- Robert Benchley