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)".
--
Oded Arbel
m-Wise mobile solutions
[EMAIL PROTECTED]
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 :)
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 say
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
would be a problem. though current implementation means that if iconv isn't
there, it will simply not encode- it won't
break.
sta
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 wi
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
define
> 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 t
so what's your vote for this?!
Sitpe
[EMAIL PROTECTED]
---
Wapme Systems AG
Vogelsanger Weg 80
40470 Düsseldorf
Tel: +49-211-74845-0
Fax: +49-211-74845-299
E-Mail: [EMAIL PROTECTED]
Internet: http://www.wapme-systems.de
--
> 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.
yep, that sounds like a good compromise I think. +1 from me.
So I guess we will have to switch the code with #ifdef HAVE_ICONV and
the according sections, right?
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 #def
kids) !
> -Original Message-
> From: Stipe Tolj [mailto:[EMAIL 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
>
>
>
>
> > -Original Message-
> > From: Stipe Tolj [mailto:[EMAIL PROTECTED]]
> > Sent: Thursday, November 21, 2002 2:10 AM
> > To: Oded Arbel
> > Cc: Andreas Fink; [EMAIL PROTECTED]
> > Subject: Re: repost: [PATCH] SMPP: data_coding (del
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 r
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 PROTEC
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 many
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 thing
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 (0x00)
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 y
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
an
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 shou
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 charac
25 matches
Mail list logo
