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

Alexander Malysh <[email protected]>
Newsgroups gmane.comp.mobile.kannel.devel
Message-ID <[email protected]>
The question is, why should you use GSM charset in external applications?
It's not portable because it only used in GSM world and if you write
external application it should also work in CDMA/TDMA/whatever. And this is
up to the SMSC module which charset to use. This is why we have this layer
of abstraction (e.g. smsbox). 

Thomas Göttgens wrote:

> 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.
> Alexander Malysh schrieb:
>> Hi,
>>
>> I see no need to pass GSM03.38 directly to smsbox. Supported charset
>> should be UTF-8 only and then it's up to SMSC module to convert to
>> anything else. We have now too much confusion with charset etc. IMHO all
>> this charset crap should be removed and only UTF-8 should be supported.
>>
>> Please, please no hacks anymore. Let us cleanup/simplify things instead
>> to confuse users even more.
>>
>> Stipe Tolj wrote:
>>
>>   
>>> Hi list,
>>>
>>> I'm trying to catch with lots of issues ;)
>>>
>>> Please find attached a simple patch that is a "RFC" version to allows
>>> direct passing of GSM 03.38 encoded byte streams via smsbox to Kannel.
>>>
>>> Why? Now, smsbox still assumes WINDOWS-1252 encoding for 7bit indicated
>>> text payloads. This means ie. various greek characters are not
>>> supported. If a user want's to send via SMPP (data_coding == 0, hence
>>> GSM default alphabet), then we'd like to provide a way to inject the
>>> byte stream directly. It will still get transcoded to our internal
>>> represenative encoding (UTF-8), but makes the "thing" easiert for the
>>> user side.
>>>
>>> Comments please.
>>>
>>> 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
>>> -------------------------------------------------------------------
>>>     
>>
>>

-- 
Thanks,
Alex
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.