RE: Phone encoding error handling without rugs

> I like a combination of this and your earlier plan.  Make the 
> STRING class take an encoding parameter which defaults to 
> ascii.  Internally it stores as UNICODE but reads and writes 
> in the encoding.
> 
> If all variants of a phone use the same encoding then it can 
> just be added in the p_ file.  If there is some other factor 
> that determines the encoding, then com_ file will need to 
> specify the parameter at decode/encode time.  Note that 
> PACKETs can take a field of type P which is accessible to all 
> other fields.
> I think it would be best if there are two parameters for 
> encoding - one for reading and one for writing.


Exampes with new keywords.
* STRING { 'encoding': 'latin-1' } field1
* STRING { 'read_encoding': 'latin-1' } field # ascii used for writing
* STRING { 'write_encoding': 'latin-1' } field # ascii used for reading
* STRING { 'read_encoding': 'latin-1', 'write_encoding': 'latin-2' } field


> The really difficult part is to make sure that round trips 
> work correctly.  For example if a contact is created named 
> Grid but is written to the phone as Grid.  Later on when we 
> read back from the phone, we'll just see Grid.  (Even worse 
> we may have dropped that letter).  Similarly we may write out 
> a ringtone with that name and then read back in a ringtone 
> with the munged name.  The usual solution to this is some 
> sort of escaping.  However we have to be careful as the phone 
> won't like it.
> Also names are stored in index files and may not match the 
> name ultimately written to disk.

I am working on simple dumbing down, removing accents and substitutions, no
dropping characters.

We will have the problem of distinguishing real change in the phones data
from munged data.

Contacts should be OK because of the index, although we will dumb down when
we read back and is that really a bad thing?

We already munge the ringtone filenames (RINGTONE_FILENAME_CHARS) not that
we shouldn't fix it.
Are you ok with handling unmunging later as a separate item. I cannot think
of how to do it using escaping, some fields are very limited on space.

Simon

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