On Fri, 2002-11-22 at 04:54, Alan McNatty wrote:
Hi Oded,
It was included - but as mentioned implied iconv was required not
optional.
No so - configure will check for it and set HAVE_ICONV only if the header file exists (which to me suggests that the library is installed - I don't know
On Sun, 2002-11-24 at 05:34, Stipe Tolj wrote:
I would leave it in gsm character set as far as possible because the receiver might want to do its own conversion. And converting it to latin1 is not lossless.
in any case not convert it if coding means its binary
yep, agreed, binary things
On Sonntag, November 24, 2002, at 04:35 Uhr, Alan McNatty wrote:
On Fri, 2002-11-22 at 21:04, Andreas Fink wrote:
Why gsm_to_latin1 if we know encoding?
We don't, well the smpp driver doesn't - that's the whole point of this
patch. In the case where the data coding is set to SMSC default
Hi
At 12:57 PM 11/24/02 +0100, Andreas Fink wrote:
We
don't, well the smpp driver doesn't - that's the whole point of this
patch. In the case where the data coding is set to SMSC default (0x00) -
the smpp driver doesn't know what decoding to do.
Well the spec says that its GSM character set.
yes but what I'm saying that is we should leave it in the character set
it is.
gsm_to_latin1 is something which is not a good idea either as it is run
also on binary and unicode content in the current code. In a situation where
you chain multiple kannels for incoming you simply
On Sonntag, November 24, 2002, at 03:36 Uhr, Oded Arbel wrote:
yes but what I'm saying that is we should leave it in the character set it is.
gsm_to_latin1 is something which is not a good idea either as it is run also on binary and unicode content in the current code. In a situation where
one point though - how will you handle drivers (like
SMPP) that allow you to send specific native character encodings instead of
UCS-2 when using non-GSM compatible alphabets ? send only in unicode
?
In that case the coding should indicate the specific native character set
On Sonntag, November 24, 2002, at 04:49 Uhr, Oded Arbel wrote:
one point though - how will you handle drivers (like SMPP) that allow you to send specific native character encodings instead of UCS-2 when using non-GSM compatible alphabets ? send only in unicode ?
In that case the coding
one point though - how will
you handle drivers (like SMPP) that allow you to send specific native
character encodings instead of UCS-2 when using non-GSM compatible alphabets
? send only in unicode ?
In that case the coding should indicate the specific native
On Fri, 2002-11-22 at 21:04, Andreas Fink wrote:
Why gsm_to_latin1 if we know encoding?
We don't, well the smpp driver doesn't - that's the whole point of this
patch. In the case where the data coding is set to SMSC default (0x00) -
the smpp driver doesn't know what decoding to do. We need to be
I would leave it in gsm character set as far as possible because the receiver might
want to do its own conversion. And converting it to latin1 is not lossless.
in any case not convert it if coding means its binary
yep, agreed, binary things should never be converted.
Stipe
[EMAIL
On Freitag, November 22, 2002, at 03:54 Uhr, Alan McNatty wrote:
Hi Oded,
It was included - but as mentioned implied iconv was required not
optional. It sounds like the preference would be to have as optional
(propagate the code with a few ifdef's, etc) and default to
gsm_to_latin1 conversion
PROTECTED]]
Sent: Thursday, November 21, 2002 2:10 AM
To: Oded Arbel
Cc: Andreas Fink; [EMAIL PROTECTED]
Subject: Re: repost: [PATCH] SMPP: data_coding (deliver_sm) votes?!
the patch tests on the header files, not on the library itself. BTW,
the patch does not work when linking
Oded Arbel wrote:
This patch was originated from m-Wise code, so I'm not sure I'm allowed to vote on
it.. but if for nothing else, at least it introduces iconv into Kannel - which I
think is mighty useful. except that, all I can say is works for me(tm).
ok, let's interpret this as +1 :)
My
On Mittwoch, November 20, 2002, at 03:42 Uhr, Stipe Tolj wrote:
Oded Arbel wrote:
This patch was originated from m-Wise code, so I'm not sure I'm allowed to vote on it.. but if for nothing else, at least it introduces iconv into Kannel - which I think is mighty useful. except that, all I can
At 03:55 PM 11/20/02 +0100, you Andreas Fink:
On Mittwoch, November 20, 2002, at 03:42 Uhr, Stipe Tolj wrote:
Oded Arbel wrote:
This patch was originated from m-Wise code, so I'm not sure I'm allowed
to vote on it.. but if for nothing else, at least it introduces iconv
into Kannel - which
My main concern is what the developers thing of having another
hard-wired dependency to third-party software, iconv in this case.
Yep, that
wouldbe a problem. though current implementation means that if iconv isn't
there, it will simply not encode- it won't
break.
On Mittwoch, November 20, 2002, at 06:52 Uhr, Oded Arbel wrote:
My main concern is what the developers thing of having another
hard-wired dependency to third-party software, iconv in this case.
Yep, that would be a problem. though current implementation means that if iconv isn't there, it
I would go for a ./configure --with-iconv where the default is without.
So people who need it can use it and others who dont, wont.
After the patch, configure will automaticly detect if iconv exist and
will use it. if it does not exist, the charset_convert function will still be
I vote +1 for rolling this patch. We allready use it and it works for us,
and its a real pain to keep our source base up to date when there are these
differences.
Sync'ing private cvs trees is not our main intention. Basically we at
Wapme do this in some sense too, but we always focus that the
the patch tests on the header files, not on the library itself. BTW,
the patch does not work when linking the executables for me, because
configure has not added any lib dependecy statements for ld.
Ok, I'd propose the following behaviour:
configure tests on iconv presence. If available sets
Hi
any reason why this didnt make it to the cvs? Also why not apply it to the
data_coding in submit_sm?
nisan
At 08:42 PM 11/6/02 +1300, Alan McNatty wrote:
Here's Oded's patch against current cvs. Is working fine for me ...
On Sat, 2002-11-02 at 11:21, Alan McNatty wrote:
In progress - am
Hi Nisan,
I guess waiting for confirmation from others that all is good. Good idea
to apply same approach to submit_sm, will have a look at that.
Cheers,
Alan
On Mon, 2002-11-18 at 10:14, Nisan Bloch wrote:
Hi
any reason why this didnt make it to the cvs? Also why not apply it to the
Here's Oded's patch against current cvs. Is working fine for me ...
On Sat, 2002-11-02 at 11:21, Alan McNatty wrote:
In progress - am building a patch against cvs for Oded's posts, and
re-post for testign etc ...
Thanks again Oded - your patches look great.
On Sat, 2002-11-02 at 00:04,
Hi
I would vote +1 for this to be rolled into CVS. We have somethng similar
but it is not as general nor as complete.
Nisan
At 01:24 PM 10/31/02 +0200, Oded Arbel wrote:
-Original Message-
From: Alan McNatty [mailto:alan;catalyst.net.nz]
ok - my mistake, according to the specs,
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
áéåí çîéùé, 31 áàå÷èåáø 2002, 23:50, Alan McNatty ëúá òì 'RE: SMPP:
data_coding (deliver_sm)':
Thanks Oded, looks good - can you post your gwlib/charset.c (I'm
guessing) you're referencing a charset_convert function which doesn't
exist in cvs
In progress - am building a patch against cvs for Oded's posts, and
re-post for testign etc ...
Thanks again Oded - your patches look great.
On Sat, 2002-11-02 at 00:04, Stipe Tolj wrote:
remeber guys to have a [PATCH] post to the mailing list if you want to
have that in the general cvs
-Original Message-
From: Alan McNatty [mailto:alan;catalyst.net.nz]
this sound like
smsc weirdness?
Yes.. :-/ actually it does.
The null character is apparently optional and can go away easily so
that's not a problem.
I'm not sure that tryig to detect if it exists before
On Thu, 2002-10-31 at 22:18, Oded Arbel wrote:
Oded, are you suggesting that gsm_to_latin1 conversion take place only
when data_coding == 0x01 or when != 0x01 (Am I readin the
specs wrong or
0x01 Ascii?). ie:
ok - my mistake, according to the specs, it should be
if (
On Thu, 2002-10-31 at 22:18, Oded Arbel wrote:
-Original Message-
From: Alan McNatty [mailto:alan;catalyst.net.nz]
this sound like
smsc weirdness?
Yes.. :-/ actually it does.
The null character is apparently optional and can go away easily so
that's not a
-Original Message-
From: Alan McNatty [mailto:alan;catalyst.net.nz]
ok - my mistake, according to the specs, it should be
if ( pdu-u.deliver_sm.data_coding == 0x00 )
charset_gsm_to_latin1(msg-sms.msgdata);
yes - I'm aware that this does not solve your
Thanks Oded, looks good - can you post your gwlib/charset.c (I'm
guessing) you're referencing a charset_convert function which doesn't
exist in cvs. cheers,
Alan
On Fri, 2002-11-01 at 00:24, Oded Arbel wrote:
-Original Message-
From: Alan McNatty [mailto:alan;catalyst.net.nz]
-Original Message-
From: Alan McNatty [mailto:alan;catalyst.net.nz]
and how do you know that the last char is a null ? I don't
think it is.
Just a guess - I have \0 at the end of each message comming through
without doing the ocstr_truncate on last char. Or does this sound like
On Thu, 2002-10-31 at 00:15, Oded Arbel wrote:
-Original Message-
From: Alan McNatty [mailto:alan;catalyst.net.nz]
and how do you know that the last char is a null ? I don't
think it is.
Just a guess - I have \0 at the end of each message comming through
without doing the
As you suggested Oded I simply need not perform the gsm_to_latin1
translation (but also remove trailing null character).
To impliment this sensibly I was hoping the data_coding would be set to
something other than 0x00 - SMSC default alphabet. Unfortunately this is
not the case which would
Alternatively we could reuse the alt-dcs used in submit_sm.
On Wed, 2002-10-30 at 12:58, Alan McNatty wrote:
As you suggested Oded I simply need not perform the gsm_to_latin1
translation (but also remove trailing null character).
To impliment this sensibly I was hoping the data_coding would
interestingly enough - leaving the message unencoded works for incomming
but somehow breaks outgoing (via http interface). The message payload is
visable in bearerbox pdu dump logs but the message arrives empty -
requires further investigation.
On Wed, 2002-10-30 at 12:58, Alan McNatty wrote:
As
Thanks Oded,
I'll put something together for this.
On Mon, 2002-10-21 at 01:45, Oded Arbel wrote:
-Original Message-
From: Alan McNatty [mailto:alan;catalyst.net.nz]
If I receive a message from a smsc in say ucs2, from what I can see in
smsc_smpp.c pdu_to_msg the msg data
Hi All,
Just trying to clear up my understanding regarding how kannel handles
smsc message charset translations. Just been through code no pdu
debugging yet.
If I receive a message from a smsc in say ucs2, from what I can see in
smsc_smpp.c pdu_to_msg the msg data always gets converted from gsm
39 matches
Mail list logo
