No objections here ?
regards
Vincent
--
Telemaque - 06200 NICE - (FR)
Service Technique/Reseau - NOC
Developpement SMS/MMS/Kiosques
http://www.telemaque.fr/
[EMAIL PROTECTED]
Tel : +33 4 93 97 71 64 (fax 68)
- Original Message -
From: Vincent CHAVANIS [EMAIL PROTECTED]
To:
Hi,
Attached is a proposal for addressing the above issue. Stipe and I
have had this discussion for a while, and I finally got round to
doing it. The main driver for this has been the need for Mbuni MMS
Gateway (www.mbuni.org), which uses Kannel's libs, to be able to
receive MMS
This is the same way of processing an incoming message (UCP 52)
Here is a review of the patch
(- whites spaces changes to follow coding rules)
(- added E50_MT checks as it's an Optional field on EMI specs 4.6)
diff -rau /gateway-cvs/gw/smsc/smsc_emi.c /gateway/gw/smsc/smsc_emi.c
---
New version that takes care about latin1 char
Vincent.
--
Telemaque - 06200 NICE - (FR)
Service Technique/Reseau - NOC
Developpement SMS/MMS/Kiosques
http://www.telemaque.fr/
[EMAIL PROTECTED]
Tel : +33 4 93 97 71 64 (fax 68)
- Original Message -
From: Vincent CHAVANIS [EMAIL
+1 for this
Only one thing: If francesco is reading: never put comments with
double slashs. Strict compilers doesn't accept this way.
+/*O_DESTROY(*body);*/
Martin.
On 9/5/06, Paul Keogh [EMAIL PROTECTED] wrote:
+1 for this.
This patch fixes the OA handling in the XML POST.
It
comments this, means remove this.
Simply delete this line.
--
Telemaque - 06200 NICE - (FR)
Service Technique/Reseau - NOC
Developpement SMS/MMS/Kiosques
http://www.telemaque.fr/
[EMAIL PROTECTED]
Tel : +33 4 93 97 71 64 (fax 68)
- Original Message -
From: Mi Reflejo [EMAIL PROTECTED]
There where days where harddisk had a limit of 2GB or 4GBThere where days where partitions had a limit of 2GB or 4GBThere where days where files had a limit of 2GB or 4GBThose days are long long gone.However if kannel's gwlib runs in full debug mode and the logfile hits 2GB, the application
2 solutions here :
- logrotate is your friend... :)
- or use 64 bits
arch
Vincent
--Telemaque - 06200 NICE - (FR)Service Technique/Reseau - NOC
Developpement SMS/MMS/Kiosqueshttp://www.telemaque.fr/[EMAIL PROTECTED]Tel : +33 4 93 97
71 64 (fax 68)
- Original Message -
From:
The 2gb limit is in 32-bit cpu: Most exactly in libc, kernel fs
drivers and VFS layer.
The limit exists because linux ports for 32bits CPUs use 32-bit
integers for file access and locking, so: 2^31 - 1 = 2GB
My solutions are:
1) You can implement LFS
2) Use XFS
3) Logrotate
M.
On 9/5/06,
Vincent says:
- logrotate is your friend... :)
- or use 64 bits arch
1. Logrotate is already my friend (it was misconfigured though...)
2. 64bit architecture is not a limit for having larger files. MacOS X
on intel has no problem creating such large files.
On 06.09.2006, at 02:34, Mi
Just a quick question: What are the performance implications of
keeping all those parts in memory? It may have some performance
penalties, specially under heavy traffic isn't it?
IMHO this should be enabled/disabled from the config files.
Besides that, it's a nice feature to have and I'd surely
11 matches
Mail list logo