RE: Unicode string handling

> 3. Need to decide on how to handle value keys like 
> 'sizeinbytes', 'constant', truncation processing, etc. for 
> both string and unicode.
 
I have taken the string keywords/parameters as applying to the strings
written to or read from the phone not bitpim, not to the unicode strings
they are converted to.

> 1. We need to propely handle unicode 'terminator'.

At the moment the user sets the terminator as a parameter. There is a
problem at the moment with handling terminators of more than one byte when
the length is restricted, the code assumes the terminator is 1 byte long.
Ther terminator parameter has no effect on the string when it is converted
to unicode.

> 2. By default, the 'encoding', 'read_encoding', and 
> 'write_encoding' should be None, which then does no 
> encoding/decoding (old behaviour).  The reasons for this 
> might be: (a) coders may want to do their own weird 
> encode/decode, (b) some phones use STRING fields as data fields.

If maintaining compatability with existing code is most important I think we
should just have a different class for unicde strings.
I think the better "techincial" solution is to have one STRING class so that
all strings look the same to the common code regardless of the phone type
and fix the phones that use the string as data to use the DATA class instead
(or list of bytes).


Simon



-------------------------------------------------------
This SF.Net email is sponsored by xPML, a groundbreaking scripting language
that extends applications into web and mobile media. Attend the live webcast
and join the prime developer group breaking into this new coding territory!
http://sel.as-us.falkag.net/sel?cmd=lnk&kid=110944&bid=241720&dat=121642