Hi Alex,
kannel-dbpool-mssql.patch looks OK except indentation. Please fix
indentation I will commit it.
Thanks,
Alex
Am 01.05.2009 um 18:21 schrieb Alejandro Guerrieri:
Ok, I've downloaded Sybase SQL Anywhere 11 for Mac and did a few
tests.
I can now officially confirm that my patch wo
Hi,
some comments to your patch:
+ /*
+ * If we don't replace the values, copy the old Dict values
to the new Dict
+*/
+ if (replace == 0) {
+ keys = dict_keys(curr->values);
+ while((key = gwlist
You're right, part of a throttling patch slept in. This wasn't
intended, sorry :P
I've removed the throttling patch, fixed the indent and the
dict_put_once.
Please see attached.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
kannel-dlr-meta-data-20090504.pa
ok, commited to cvs.
Thanks,
Alex
Am 04.05.2009 um 13:11 schrieb Alejandro Guerrieri:
You're right, part of a throttling patch slept in. This wasn't
intended, sorry :P
I've removed the throttling patch, fixed the indent and the
dict_put_once.
Please see attached.
Regards,
--
Alejandr
Please find attached the patch to userguide.Regards, --Alejandro Guerrieriaguerri...@kannel.org
kannel-dbpool-mssql-doc-20090504.patch
Description: Binary data
On 04/05/2009, at 14:53, Alejandro Guerrieri wrote:Indentation fixed. I'm preparing an userguide.xml patch as well, will commit
Hi,
Just a quick question: I'm checking on different smsc's
implementations and I've noticed that, despite that dlr_add and
dlr_find are usually called using conn->id for the first parameter
(smsc), on some smsc's conn->name is used instead:
gw/smsc/smsc_cimd2.c: dlr_add(conn->name, ts,
in all cases the conection name,is being passed. If I remember right
it was mainly used for logging purposes.
apparently there where cases in EMI where conn->id was empty or so.
unifying it would make sense in my eyes.
Note: I wrote the initial implementation in SMPP and EMI/UCP. The
CIMD2 an
Ok, so something similar to this would make sense I guess:
gw/smsc/smsc_emi.c: dlr_add((conn->id ? conn->id : privdata->name),
ts, m);
I think on most if not all SMSC's connections the id is a mandatory
parameter anyway. So unless it's not mandatory, the "id" would make
more sense.
Reg
We were facing a problem when dealing with multiple binds to the same
carriers.
Some of the carriers we're working with have SMSC's on
twogeographically-distant places. They asked us to connect to both of
them from our also replicated kannel clients.
So, we have two identical connections
Please check on my latest patch over the "smsc-dlr-alias" parameter.
To use the dlr_alias, it modifies the code on the smsc's that were
using the ->name instead of ->id to be as follows:
-msg = dlr_find(conn->name, timestamp, destination, code);
+msg = dlr_find((conn->dlr_ali
Hi Alex,
why do you need this?
here is needed config for you:
# first connection
group = smsc
smsc-id = mylink
allowed-smsc = mylink;mylink1
# second connection
group = smsc
smsc-id = mylink
allowed-smsc = mylink;mylink2
So you can send with &smsc=mylink and bearerbox loadbalance between
tw
Well, we tried that approach in the first place. While it might be
appropriate on many cases, we'd lose control over the individual links
that way.
For our particular case, that's a showstopper, and it might be for
others as well:
* You wouldn't be able to manually shutdown one of the bin
commited to cvs.
Am 04.05.2009 um 14:53 schrieb Alejandro Guerrieri:
Indentation fixed. I'm preparing an userguide.xml patch as well,
will commit it as soon as is ready.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 04/05/2009, at 11:36, Alexander Malysh wrote:
Hi Alex,
kann
commited to cvs.
Thanks,
Alex
Am 04.05.2009 um 17:35 schrieb Alejandro Guerrieri:
Please find attached the patch to userguide.
Regards,
--
Alejandro Guerrieri
aguerri...@kannel.org
On 04/05/2009, at 14:53, Alejandro Guerrieri wrote:
Indentation fixed. I'm preparing an userguide.xml patch
Am 04.05.2009 um 23:23 schrieb Alejandro Guerrieri:
Well, we tried that approach in the first place. While it might be
appropriate on many cases, we'd lose control over the individual
links that way.
For our particular case, that's a showstopper, and it might be for
others as well:
* Y
Shall I interpret that as a -1? ;)
--
Alejandro Guerrieri
aguerri...@kannel.org
On 04/05/2009, at 23:40, Alexander Malysh wrote:
Am 04.05.2009 um 23:23 schrieb Alejandro Guerrieri:
Well, we tried that approach in the first place. While it might be
appropriate on many cases, we'd lose con
16 matches
Mail list logo