Re: Unicode string handling

> >That is because you are treating the terminator as a byte.
>
> Because that's how it is currently defined and implemented.  
> That's not to say it can't be changed, but it is what it is.

The terminator should definitely be in the phone encoding since
the data comes back from the phone in the phone's encoding.

> That was why I suggested the idea of not doing any unicode 
> processing if no codec is specified.  

Ultimately unicode processing has to happen somewhere.  At the
moment it happens when we try to store the strings into the
database when the user gets a bewildering exception.  I way
prefer making that a known exception somewhat closer to the
code that deals with phone data.  ie today we already generate
exceptions with non-ascii data.  Having that exception move
into one place in the STRING class seems way more sensible.

> >I think it is especially dangerous abandoning old phones.
>
> I don't think that's what we're saying, 

If there are two string classes then that is exactly what
is happening.  The old phones will all end up using STRING
and the new code/models will use UNICODE.  And newly 
developed and updated code (eg new phonebook, calendar,
memo etc) will only be tested against UNICODE and slowly
lose compatibility with STRING.  Let a period of time pass
and it will be a big developer burden to update the old
phone code.  That is why I think it is better to update the
code anyway.  If people do use and do encounter issues
they will be way easier to fix.

> >If people in that community stop paying attention, or don't care
> >about particular models then I don't see the point of BitPim also 
> >doing so.
>
> I think we do care, otherwise we wouldn't be concerned about 
> breaking support to existing/old phones.

That is ultimately your call.  I personally don't care about 
breaking support for old phones.  I'd rather have the code be
up to date so if someone does use it we can easily fix it, 
than let it languish, working in theory, but not be able to
fix it if someone reports an issue.

Roger


-------------------------------------------------------
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