Re: Proposed nsIFile and nsILocalFile Changes - MUST READ

[Patrick Beard]

At 10:19 AM -0800 3/2/01, Doug Turner wrote:
>Mike Shaver wrote:
>  > I second Jon Smirl's concern over the fate of XPCOM_STANDALONE, and am
>>  somewhat saddened to see that we want to make our whole product bear the
>>  memory and computation burden of UCS-2/UTF-16 paths when the _vast_
>>  majority of our paths live happily in 7 bits.
>
>CCing ftang.
>Frank, you added unicode paths to the nsIFile.  A couple of questions:
>
>Why do we need unicode paths on the nsIFile?
>Can't consumer convert before calling into this interface?  Can we have macros
>outside of this interface?
>What about callers from JS via xpconnect, what charset are those paths used
>when being converted to char*'s?

The Mac OS file APIs now support direct manipulation of files with 
UNICODE. The Mac filesytem has always a had a wider range of 
character possibilities in filenames than these other systems. I 
think it's crucial that our APIs be as forward looking as possible. 
We're already taking the hit for UNICODE in JavaScript and other 
sub-systems. I don't think the extra cost is really an issue, and 
will prove to be the right choice in the very near future.

If we use simply 8-bit characters in our file APIs, then which encoding?

- Patrick
-- 

// Patrick C. Beard
// Java Runtime Enthusiast -- "Will invoke interfaces for food."
// mailto:[EMAIL PROTECTED]