latin1 again in charset.c ???

Hi, Stipe, could you please explain this commit? Why we should care of any external boxes? If your external box needs these functions then please add those to files in your extenal box. I'm --1 for such overloading of libraries. +2007-01-07 Stipe Tolj stolj at kannel.org +*

Re: latin1 again in charset.c ???

I think as gwlib is a generic lib, the functions should stay there even kannel doesnt use it directly at the current time. On 08.01.2007, at 14:25, Alexander Malysh wrote: Hi, Stipe, could you please explain this commit? Why we should care of any external boxes? If your external box needs

Re: [PATCH] Re: MO Concatenation

Hi Paul, +1 for the at2 part. -1 for the reassemble part. Your patch will never work reliable because not only msisdn + refnum should be considered. Reassemble should have triple as key: SMSC, msisdn, refnum. IMO bb_boxc.c is the wrong place for this, bb_smscconn suites better because

Re: [PATCH] Mime multipart parsing

Vincent CHAVANIS wrote: The test is trivial, it does not crash anymore with this patch ;) yeah... but we need a more generic test-suite for it. Did you mention you're on vation?... Hey, obviously you have then enough time beside the daily business! ;p Stipe

Re: latin1 again in charset.c ???

Hi Andreas, you are right about gwlib that this is generic library. But why should this library include broken by design functions? It's just impossible to convert GSM to latin1 w/o loss so why include such functions? Am 08.01.2007, 14:32 Uhr, schrieb Andreas Fink [EMAIL PROTECTED]: I

Re: latin1 again in charset.c ???

Andreas Fink wrote: I think as gwlib is a generic lib, the functions should stay there even kannel doesnt use it directly at the current time. +1 on Andreas opinion. Since there is no elegant way (ie. via iconv) to convert from/to gsm charset, kannel as SMS gateway lib provider should

Re: latin1 again in charset.c ???

Alexander Malysh wrote: Hi Andreas, you are right about gwlib that this is generic library. But why should this library include broken by design functions? It's just impossible to convert GSM to latin1 w/o loss so why include such functions? that's not the point I guess. iconv() also

Re: [PATCH] Re: MO Concatenation

Alexander Malysh wrote: Hi Paul, +1 for the at2 part. -1 for the reassemble part. Your patch will never work reliable because not only msisdn + refnum should be considered. Reassemble should have triple as key: SMSC, msisdn, refnum. IMO bb_boxc.c is the wrong place for this, bb_smscconn

Re: [PATCH] Re: MO Concatenation

On Jan 08, 2007, at 17:04, Stipe Tolj wrote: Alexander Malysh wrote: Hi Paul, +1 for the at2 part. -1 for the reassemble part. Your patch will never work reliable because not only msisdn + refnum should be considered. Reassemble should have triple as key: SMSC, msisdn, refnum. IMO

Re: latin1 again in charset.c ???

FYI, I had to do EXACTLY the same on my application when I built a independent gwlib package to run as shared library on my Mac simply because I had a latin1 interface talking to binary GSM. On 08.01.2007, at 14:53, Stipe Tolj wrote: Andreas Fink wrote: I think as gwlib is a generic

Re: [PATCH] Re: MO Concatenation

Am 08.01.2007, 15:50 Uhr, schrieb Paul Bagyenda [EMAIL PROTECTED]: On Jan 08, 2007, at 17:04, Stipe Tolj wrote: Alexander Malysh wrote: Hi Paul, +1 for the at2 part. -1 for the reassemble part. Your patch will never work reliable because not only msisdn + refnum should be considered.

Re: [PATCH] Re: MO Concatenation

Watch out here If you have TWO EMI/UCP connection to the same SMSC's (like to overcome speed limitations while windowing = 0) which have the same id, then they actually can have one SMS come in on one link and the other on the other. For the SMSC its just two different SMS's. Same is

RE: [PATCH] Re: MO Concatenation

The triple key is not valid. From personal experience I was getting the SMS parts from all SMSC's not the one that transmitted the first part only. All the operators I worked with do the same thing. So the key should remain msisdn + refnum only. Dimitris Evmorfopoulos -Original

Re: [PATCH] Re: MO Concatenation

On 08.01.2007, at 17:38, Δημήτρης Ευμορφόπουλος wrote: The triple key is not valid. From personal experience I was getting the SMS parts from all SMSC's not the one that transmitted the first part only. All the operators I worked with do the same thing. So the key should remain msisdn

[PATCH] Kannel Indentation

Since i get sick patching kannel because the indentation (spaces mixed with tab [mixed 4 and 8 spaces too]) I decided to fix it. There is the huge patch. divide in two files gwlibindent.patch and gwindent.patch I did it completely by hand and then for sanity check i did: # diff -NrEbwB* dir1

Re: [PATCH] Kannel Indentation

Hi, On 1/8/07, Mi Reflejo [EMAIL PROTECTED] wrote: Since i get sick patching kannel because the indentation (spaces mixed with tab [mixed 4 and 8 spaces too]) I decided to fix it. There is the huge patch. [...] I did it completely by hand and then for sanity check i did: # diff -NrEbwB* dir1

Re: [PATCH] Kannel Indentation

The problem is that i try vim autoindent, bcpp and other tools and no one makes it perfect. So i decided to do it by hand M On 1/8/07, Enver ALTIN [EMAIL PROTECTED] wrote: Hi, On 1/8/07, Mi Reflejo [EMAIL PROTECTED] wrote: Since i get sick patching kannel because the indentation (spaces

RE: [PATCH] Re: MO Concatenation

So you mean msisdn + refnum + smsc-group-id not smscid ... That is valid! BTW, what do you think that the time-to-live for each part should be? We show that anything over 3 minutes is already too much. Dimitris Evmorfopoulos -Original Message- From: Andreas Fink [mailto:[EMAIL