Re: [PATCH] support GSM 03.38 encoding byte stream via smsbox's sendsms

Stipe Tolj <[email protected]>
Newsgroups gmane.comp.mobile.kannel.devel
Organization tolj.org system architecture
Message-ID <[email protected]>
Thomas Göttgens schrieb:
> Alexander,
> 
> you are right in principle. But IF there's another charset that has the 
> right to live alongside UFT-8 input wise it is the GSM charset,
> since some applications may hand in strings already encoded for GSM 
> transport. After all this is the 'target' charset for transport
> and you should not be required to convert this to UTF-8 externally for 
> feeding to SMSBOX. What happens inside of the
> SMSBOX (coversion to UTF-8 and back) however is of no concern to 
> developers of external applications.

now, I agree with both argumentations here... yeah, the diplomatic way ;)

Alex is right to have a "uniqueness" against the external sub-systems (backend 
HTTP server, client).

But Thomas has a good catch here. My main concern is: backend applications 
(let's say ringtone handlers or anything fancy of that kind) handle GSM 03.38 
internally. Now they need to "convert" from GSM to UTF8 to pass to smsbox. 
But(!), non of the "standard" application frameworks, JSP, PHP, ASP can do that 
on their own, mainly because iconv() doesn't know anything about GSM convertion. 
So "explaining" people how to transcode from GSM to UTF8 is the SAME MESS, right?

We could come to an adequate concensus by: using UTF8 as default encoding as we 
do internally too, but still allow setting any other encoding via 'charset' 
value. How is that?

Stipe

-------------------------------------------------------------------
Kölner Landstrasse 419
40589 DÃŒsseldorf, NRW, Germany

tolj.org system architecture      Kannel Software Foundation (KSF)
http://www.tolj.org/              http://www.kannel.org/

mailto:st_{at}_tolj.org           mailto:stolj_{at}_kannel.org
-------------------------------------------------------------------
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.