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
21 matches
Mail list logo
