AT parsing
Hello devel,
I was in discussion with Oded about something (something else, btw.).
And I would like to ask the following to everybody in the list.
Question:
At this moment, each function implements its own AT parsing, most of it
is done (rudimentarily) in at2_wait_modem_command.
Would Kannel benefit from a general AT responses/indications parser?
I am thinking of something like:
/* this function takes a AT response or indication and returns the
* parameters as an Octstr-list.
* returns 0 on success or -1 on error.
*/
int at2_parse_at(Octstr *line, List **result)
{
...
}
But any other result parameters that can be easily used in a calling
function is also good for me ;)...
Reason for this proposal is that in similar projects, I did we also
started out with simple search functions, etc. But on the way -while
more functionality is added- these things were copy/pasted into the
new functions, causing redundancy.
Above that, parsing functions like that tend to be readable very
bad, because of all the exceptions you have to take into account: Are
we expecting / getting quotes or not. And what if we only get one
quote without a closing one... What if a parameter is skipped in the
response... etc.
--
Best regards,
Rene mailto:[EMAIL PROTECTED]
RE: [VOTE] changing Octstr comparison behaviour (was: converting to and from HTML 4 entities)
My vote is to use strcmp only and let the underlying libc to do the proper work concerning locale. Angel Fradejas Mediafusión España, S.A. [EMAIL PROTECTED] www.mediafusion.es Tel. +34 91 252 32 00 Fax +34 91 572 27 08 -Mensaje original- De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Oded Arbel Enviado el: lunes 23 de septiembre de 2002 20:00 Para: Rene Kluwen / Chimit Software Solutions CC: [EMAIL PROTECTED] Asunto: [VOTE] changing Octstr comparison behaviour (was: converting to and from HTML 4 entities) > -Original Message- > From: Rene Kluwen / Chimit Software Solutions > MHO on A couple of things: > - strcmp is (should be) Locale specific, according to POSIX. > - The difference in octstr_compare and octstr_str_compare are at least > inconsequent. They should both use either use strcmp or memcmp to > avoid confusions (my vote is for strcmp). I'd like to put a vote up on the list for changing the current behaviour of the comparison functions in octstr.[ch] to be consistant, and whether they should all use memcmp() or strcmp(). I'm voting to change the current behaviour so that it will be consistent and use only strcmp() or stricmp() internally. > - The discussion about whether entities should be compared to > Locale or > to byte order is more or less void. Entities do not contain > locale-specific characters by definition. Because that is why entities > are used for. oh, right :-) thanks for pointing that out. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. If they wrote error messages in Haiku ? The ten thousand things How long do any persist? Netscape, too, has gone. > OA> -Original Message- > OA> From: Andreas Fink [mailto:[EMAIL PROTECTED]] > OA> Sent: Monday, September 23, 2002 4:13 PM > OA> To: Oded Arbel > OA> Cc: [EMAIL PROTECTED] > OA> Subject: Re: Octstr support for converting to and from > HTML 4 entities. > > > > > > OA> Oh. that was me - sorry. its no hard rule, but basicly > what I meant is - don't use c strings for doing complicated > stuff that the Octstr sub system handles better and more > safely. do use c-string > OA> library calls for simple stuff that the library call > would do better, especially if the call doesnot modify the > content of the string (hence - no risk for buffer overflows). > for example, when you > OA> want to compare octstrings you can use > strcmp(octstr_get_cstr( or you can use octstr_compare(). > this is the border line case IMO, where in this case I would > have used the octstr_compare() as > OA> it involves fewer calls. you have already demonstrated > that you can choose correctly between complexity and safety, > and you can make the same decisions here. most importantly - > don't take > OA> anything said by Kannel developers , especially me, as > hard truth - those are simply recomendations. if we hate your > code so much (not that I do) - we can change when it is in > the CVS :-) > > > > OA> strcmp(octstr_get_cstr(... and octstr_compare() behave > DIFFERENTLY. > OA> if I remember correctly octstr_compare is case sensitive > where strcmp is more or less simply comparing the bytes. > > OA> strcmp should be locale sensitive as per the POSIX > standard, IIRC. it has nothing to do with case sensitivity. > > OA> I wouldnt count on it to compare on upper/lowercase and > even diacritical characters. > > OA> Well - you should. on the contrary - while strcmp is (or > at least should be) locale aware, octstr_compare() uses > memcmp() internally, which does simple byte comparison. OTOH, > octstr_str_compare() > OA> which IMO should behave no different then > octstr_compare() uses strcmp() internally. > > > OA> as you can see comparing strings is not always obvious. > but it should be at least consistent. So if you can write a > parameter in a config file in upper or lower case and it > doesn't really matter, > OA> suddendly using strcmp would make the behaviour really strange. > > OA> if you want to be case insensitive, you can use stricmp() > or octstr_case_compare(). since Rene uses > octstr_str_compare() which internally uses the locale > sensitive strcmp(), maybe we should > OA> change it to use octstr_compare() somehow so that > comparison would be byte ordered (locale insensitive) and > sort the entity list to match ? > > OA> octstr.c is an abstraction layer. Thats what it is there > for. So use it for that purpose. > OA> and frankly, the memory checking stuff is really useful > in it. I'm fixing a few dozen memory leaks by using it. It > points with the finger to it all the time. Very easy to fix this way. > > OA> stdc sting.h stuff doesn't give you any of that. > > OA> That's why its always a good idea to use it. sometimes > though, if you are careful, the std lib calls provide extra > performance which is also important. > > OA> -- > OA> Oded Arbel > OA> m-Wise mobile solutions > OA> [EMAIL PROTECTED] > > OA> +972-9-9581711 (116) > OA> +972-67-
RE: Re[2]: [PATCH] Octstr support for converting to and from HTML 4 entities.
> -Original Message- > From: Rene Kluwen / Chimit Software Solutions > Are you having a memory leak while replacing html entities? > Could you send me the source of test_octstr_format that you > are having problems with? > So I can have a look at it. I am not sure if showing leaks is on by > default. But I adapted one of the programs in checks/ and nothing > shows a leak with me so far. > >> P.S. > >> the test_octstr_format detects two memory leaks - from first > >> look I didn't > >> understand what is causing them. could someone familiar with > >> code please > >> take > >> a look ? Nope - no memory leak. what I noticed was a bug in my changes to the test program and not anything in Octstr. sorry. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. Reasons to Run Away 35-"Because, when the GM said that there was an 'ogre' in the cave, he was referring to a BIG tank with tac-nukes and Bi-Phase Carbide armor..."
[VOTE] changing Octstr comparison behaviour (was: converting to and from HTML 4 entities)
> -Original Message- > From: Rene Kluwen / Chimit Software Solutions > MHO on A couple of things: > - strcmp is (should be) Locale specific, according to POSIX. > - The difference in octstr_compare and octstr_str_compare are at least > inconsequent. They should both use either use strcmp or memcmp to > avoid confusions (my vote is for strcmp). I'd like to put a vote up on the list for changing the current behaviour of the comparison functions in octstr.[ch] to be consistant, and whether they should all use memcmp() or strcmp(). I'm voting to change the current behaviour so that it will be consistent and use only strcmp() or stricmp() internally. > - The discussion about whether entities should be compared to > Locale or > to byte order is more or less void. Entities do not contain > locale-specific characters by definition. Because that is why entities > are used for. oh, right :-) thanks for pointing that out. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. If they wrote error messages in Haiku ? The ten thousand things How long do any persist? Netscape, too, has gone. > OA> -Original Message- > OA> From: Andreas Fink [mailto:[EMAIL PROTECTED]] > OA> Sent: Monday, September 23, 2002 4:13 PM > OA> To: Oded Arbel > OA> Cc: [EMAIL PROTECTED] > OA> Subject: Re: Octstr support for converting to and from > HTML 4 entities. > > > > > > OA> Oh. that was me - sorry. its no hard rule, but basicly > what I meant is - don't use c strings for doing complicated > stuff that the Octstr sub system handles better and more > safely. do use c-string > OA> library calls for simple stuff that the library call > would do better, especially if the call doesnot modify the > content of the string (hence - no risk for buffer overflows). > for example, when you > OA> want to compare octstrings you can use > strcmp(octstr_get_cstr( or you can use octstr_compare(). > this is the border line case IMO, where in this case I would > have used the octstr_compare() as > OA> it involves fewer calls. you have already demonstrated > that you can choose correctly between complexity and safety, > and you can make the same decisions here. most importantly - > don't take > OA> anything said by Kannel developers , especially me, as > hard truth - those are simply recomendations. if we hate your > code so much (not that I do) - we can change when it is in > the CVS :-) > > > > OA> strcmp(octstr_get_cstr(... and octstr_compare() behave > DIFFERENTLY. > OA> if I remember correctly octstr_compare is case sensitive > where strcmp is more or less simply comparing the bytes. > > OA> strcmp should be locale sensitive as per the POSIX > standard, IIRC. it has nothing to do with case sensitivity. > > OA> I wouldnt count on it to compare on upper/lowercase and > even diacritical characters. > > OA> Well - you should. on the contrary - while strcmp is (or > at least should be) locale aware, octstr_compare() uses > memcmp() internally, which does simple byte comparison. OTOH, > octstr_str_compare() > OA> which IMO should behave no different then > octstr_compare() uses strcmp() internally. > > > OA> as you can see comparing strings is not always obvious. > but it should be at least consistent. So if you can write a > parameter in a config file in upper or lower case and it > doesn't really matter, > OA> suddendly using strcmp would make the behaviour really strange. > > OA> if you want to be case insensitive, you can use stricmp() > or octstr_case_compare(). since Rene uses > octstr_str_compare() which internally uses the locale > sensitive strcmp(), maybe we should > OA> change it to use octstr_compare() somehow so that > comparison would be byte ordered (locale insensitive) and > sort the entity list to match ? > > OA> octstr.c is an abstraction layer. Thats what it is there > for. So use it for that purpose. > OA> and frankly, the memory checking stuff is really useful > in it. I'm fixing a few dozen memory leaks by using it. It > points with the finger to it all the time. Very easy to fix this way. > > OA> stdc sting.h stuff doesn't give you any of that. > > OA> That's why its always a good idea to use it. sometimes > though, if you are careful, the std lib calls provide extra > performance which is also important. > > OA> -- > OA> Oded Arbel > OA> m-Wise mobile solutions > OA> [EMAIL PROTECTED] > > OA> +972-9-9581711 (116) > OA> +972-67-340014 > > OA> ::.. > OA> If you don't care where you are, then you ain't lost. > > > > > -- > Best regards, > Renemailto:[EMAIL PROTECTED] > >
Re[2]: Octstr support for converting to and from HTML 4 entities.
Hello List, MHO on A couple of things: - strcmp is (should be) Locale specific, according to POSIX. - The difference in octstr_compare and octstr_str_compare are at least inconsequent. They should both use either use strcmp or memcmp to avoid confusions (my vote is for strcmp). - The discussion about whether entities should be compared to Locale or to byte order is more or less void. Entities do not contain locale-specific characters by definition. Because that is why entities are used for. At the same time an excuse, because I started this discussion. Background behind that: that was that I saw that octstr_str_compare was using strcmp and the normal str_compare used memcmp. And I did not know if there was any special reason for it. Also my the patch that I posted first, did a byte compare on each character. So I just wanted to point out that there was a difference. -- Rene... Monday, September 23, 2002, 4:32:37 PM, you wrote: OA> -Original Message- OA> From: Andreas Fink [mailto:[EMAIL PROTECTED]] OA> Sent: Monday, September 23, 2002 4:13 PM OA> To: Oded Arbel OA> Cc: [EMAIL PROTECTED] OA> Subject: Re: Octstr support for converting to and from HTML 4 entities. OA> Oh. that was me - sorry. its no hard rule, but basicly what I meant is - don't use c strings for doing complicated stuff that the Octstr sub system handles better and more safely. do use c-string OA> library calls for simple stuff that the library call would do better, especially if the call doesnot modify the content of the string (hence - no risk for buffer overflows). for example, when you OA> want to compare octstrings you can use strcmp(octstr_get_cstr( or you can use octstr_compare(). this is the border line case IMO, where in this case I would have used the octstr_compare() as OA> it involves fewer calls. you have already demonstrated that you can choose correctly between complexity and safety, and you can make the same decisions here. most importantly - don't take OA> anything said by Kannel developers , especially me, as hard truth - those are simply recomendations. if we hate your code so much (not that I do) - we can change when it is in the CVS :-) OA> strcmp(octstr_get_cstr(... and octstr_compare() behave DIFFERENTLY. OA> if I remember correctly octstr_compare is case sensitive where strcmp is more or less simply comparing the bytes. OA> strcmp should be locale sensitive as per the POSIX standard, IIRC. it has nothing to do with case sensitivity. OA> I wouldnt count on it to compare on upper/lowercase and even diacritical characters. OA> Well - you should. on the contrary - while strcmp is (or at least should be) locale aware, octstr_compare() uses memcmp() internally, which does simple byte comparison. OTOH, octstr_str_compare() OA> which IMO should behave no different then octstr_compare() uses strcmp() internally. OA> as you can see comparing strings is not always obvious. but it should be at least consistent. So if you can write a parameter in a config file in upper or lower case and it doesn't really matter, OA> suddendly using strcmp would make the behaviour really strange. OA> if you want to be case insensitive, you can use stricmp() or octstr_case_compare(). since Rene uses octstr_str_compare() which internally uses the locale sensitive strcmp(), maybe we should OA> change it to use octstr_compare() somehow so that comparison would be byte ordered (locale insensitive) and sort the entity list to match ? OA> octstr.c is an abstraction layer. Thats what it is there for. So use it for that purpose. OA> and frankly, the memory checking stuff is really useful in it. I'm fixing a few dozen memory leaks by using it. It points with the finger to it all the time. Very easy to fix this way. OA> stdc sting.h stuff doesn't give you any of that. OA> That's why its always a good idea to use it. sometimes though, if you are careful, the std lib calls provide extra performance which is also important. OA> -- OA> Oded Arbel OA> m-Wise mobile solutions OA> [EMAIL PROTECTED] OA> +972-9-9581711 (116) OA> +972-67-340014 OA> ::.. OA> If you don't care where you are, then you ain't lost. -- Best regards, Renemailto:[EMAIL PROTECTED]
RE: [REPOST] [PATCH] emi2 reconnection behaviour
-Original Message-From: Angel Fradejas [mailto:[EMAIL PROTECTED]] >> If you don't want a reconnection, you just can set the "reconnect-delay" >> to a very high value, and you're done (as in the rest of drivers). > Wouldn't that mean that eventually Kannel will reconnect ? Well I meant a VERY high value, let's say 3. That's almost 10 years Ok, it will work - but it doesn't sound like the "Right Thing(tm)" :-\ --Oded Arbelm-Wise mobile solutions[EMAIL PROTECTED] +972-9-9581711 (116)+972-67-340014 ::..aibohphobia, n., The fear of palindromes.
RE: [REPOST] [PATCH] emi2 reconnection behaviour
>> If you don't want a reconnection, you just can set the "reconnect-delay" >> to a very high value, and you're done (as in the rest of drivers). > Wouldn't that mean that eventually Kannel will reconnect ? Well I meant a VERY high value, let's say 3. That's almost 10 years Angel.
RE: [REPOST] [PATCH] emi2 reconnection behaviour
-Original Message-From: Angel Fradejas [mailto:[EMAIL PROTECTED]]Sent: Monday, September 23, 2002 4:39 PMTo: Oded ArbelCc: [EMAIL PROTECTED]Subject: RE: [REPOST] [PATCH] emi2 reconnection behaviour Oded, that's exactly what I did in my patch and wanted to do I even removed the "retry" option, as the rest of driversbut it seems not everybody agrees with that :-( I think the "retry" directive is a bad idea, whatever it defaults to. I don't need it either, but if other people do.. well.. but do leave the default to 'yes' to match the behaviour of all other drivers. If you don't want a reconnection, you just can set the "reconnect-delay" to a very high value, and you're done (as in the rest of drivers). Wouldn't that mean that eventually Kannel will reconnect ? How does German users operate Kannel : start it up, the driver tries to connect, fails and shutdown. and then what do you do when you want the connection to be established in order to send an MT ? --Oded Arbelm-Wise mobile solutions[EMAIL PROTECTED] +972-9-9581711 (116)+972-67-340014 ::..He's dead, Jim. You grab his wallet, I'll grab his tricorder. So I guess we need consensus here. Angel. -Mensaje original-De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Oded ArbelEnviado el: lunes 23 de septiembre de 2002 16:34Para: Angel FradejasCC: [EMAIL PROTECTED]Asunto: RE: [REPOST] [PATCH] emi2 reconnection behaviour I'd suggest to set the default of retry as 'yes', as most users do use EMI over TCP/IP. --Oded Arbelm-Wise mobile solutions[EMAIL PROTECTED] +972-9-9581711 (116)+972-67-340014 ::.."Existence is not only temporary, it's pointless!" -- Calvin and Hobbes -Original Message-From: Angel Fradejas [mailto:[EMAIL PROTECTED]]Sent: Monday, September 23, 2002 4:13 PMTo: Andreas FinkCc: [EMAIL PROTECTED]Subject: RE: [REPOST] [PATCH] emi2 reconnection behaviour Ok, sounds reasonable for me. I didn't know that fact for Germany. So I can resubmit the patch, keeping the "retry" directive, with "no" as default (as it is actually), and fix the behaviour with a "reconnect-delay" directive, with a 10 seconds default. Is this ok? Angel. -Mensaje original-De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Andreas FinkEnviado el: lunes 23 de septiembre de 2002 13:44Para: Angel FradejasCC: [EMAIL PROTECTED]Asunto: Re: [REPOST] [PATCH] emi2 reconnection behaviourOn Montag, September 23, 2002, at 10:33 Uhr, Angel Fradejas wrote: >Somehow I disageee. Some folks use EMI/UCP on dialup links so you don't > want to have it retry all the time and open the link. >"It always assumes reconnection" is thus not a good idea. Then we could mark it as a compatibility-breaker in the next release. I think there are much more people using it over direct tcp links than dialup ones. This is definitively wrong for users in Germany as the german carriers don't allow connectivity over the internet usually but only over 2Mbps permanent leased line (very expensive) or ISDN dial-on demand dialup to a private network.I think we simply should fix the existing behaviour instead of inventing another new one.Andreas FinkGlobal Networks, Inc.--Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333Global Networks, Inc. Schwarzwaldallee 16, 4058 Basel, SwitzerlandWeb: http://www.global-networks.ch/ [EMAIL PROTECTED]--Member of the GSM Association
RE: [REPOST] [PATCH] emi2 reconnection behaviour
Oded, that's exactly what I did in my patch and wanted to do I even removed the "retry" option, as the rest of driversbut it seems not everybody agrees with that :-( I think the "retry" directive is a bad idea, whatever it defaults to. If you don't want a reconnection, you just can set the "reconnect-delay" to a very high value, and you're done (as in the rest of drivers). So I guess we need consensus here. Angel. -Mensaje original-De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Oded ArbelEnviado el: lunes 23 de septiembre de 2002 16:34Para: Angel FradejasCC: [EMAIL PROTECTED]Asunto: RE: [REPOST] [PATCH] emi2 reconnection behaviour I'd suggest to set the default of retry as 'yes', as most users do use EMI over TCP/IP. --Oded Arbelm-Wise mobile solutions[EMAIL PROTECTED] +972-9-9581711 (116)+972-67-340014 ::.."Existence is not only temporary, it's pointless!" -- Calvin and Hobbes -Original Message-From: Angel Fradejas [mailto:[EMAIL PROTECTED]]Sent: Monday, September 23, 2002 4:13 PMTo: Andreas FinkCc: [EMAIL PROTECTED]Subject: RE: [REPOST] [PATCH] emi2 reconnection behaviour Ok, sounds reasonable for me. I didn't know that fact for Germany. So I can resubmit the patch, keeping the "retry" directive, with "no" as default (as it is actually), and fix the behaviour with a "reconnect-delay" directive, with a 10 seconds default. Is this ok? Angel. -Mensaje original-De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Andreas FinkEnviado el: lunes 23 de septiembre de 2002 13:44Para: Angel FradejasCC: [EMAIL PROTECTED]Asunto: Re: [REPOST] [PATCH] emi2 reconnection behaviourOn Montag, September 23, 2002, at 10:33 Uhr, Angel Fradejas wrote: >Somehow I disageee. Some folks use EMI/UCP on dialup links so you don't > want to have it retry all the time and open the link. >"It always assumes reconnection" is thus not a good idea. Then we could mark it as a compatibility-breaker in the next release. I think there are much more people using it over direct tcp links than dialup ones. This is definitively wrong for users in Germany as the german carriers don't allow connectivity over the internet usually but only over 2Mbps permanent leased line (very expensive) or ISDN dial-on demand dialup to a private network.I think we simply should fix the existing behaviour instead of inventing another new one.Andreas FinkGlobal Networks, Inc.--Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333Global Networks, Inc. Schwarzwaldallee 16, 4058 Basel, SwitzerlandWeb: http://www.global-networks.ch/ [EMAIL PROTECTED]--Member of the GSM Association
m-notification-ind to t68i
Hi all, Has anybody manage to send m-notification-ind to t68i ? If so can you give me an example to the parameters you use ? (pap and X_MMS headers ) my handset seem to get the information but nothing happens. Best regards, Lior Barne'a, Infrastructures developer, m-Wise mobile solutions. [EMAIL PROTECTED] +972-9-9581711 (120) +972-55-679228
RE: [PATCH] Octstr support for converting to and from HTML 4 entities.
> -Original Message- > From: Rene Kluwen [mailto:[EMAIL PROTECTED]] > 1. > Don't forget to include the octstr_insert_char patch either. > This code won't work without it (the patch). I do not believe > any code that > uses it works as it is now. > (a quick grep yielded that indeed there is no code, using it atm). already submitted to CVS - thanks for the fix, and sorry for not notifying you :-) > 2. > test_octstr_format: Where can I find this function? Its not a function, but a test program - you can find it under the test directory. I use it to test things with octstr instead of writing my own test program (I'm lazy - one of the three virtues of a programmer ;-) -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. The most exciting phrase to hear in science, the one that heralds new discoveries, is not "Eureka!" but "hm... that's funny..." -- Isaac Asimov > > > - Original Message - > Date: Mon September 23, 2002 04:55 PM > From: Oded Arbel <[EMAIL PROTECTED]> > To: Kannel-devel (E-mail) <[EMAIL PROTECTED]> > Subject: [PATCH] Octstr support for converting to and from > HTML 4 entities. > > Hi list. > > Here's the full HTML entity patch based on the work of Rene Kluwen > (Thanks !) > I only tested it to work as expected (both 'to' and 'from') > and that no > memory leaks are present - have not benchmarked it, but I > think that the > code > by Rene should prove much faster then my original hack. > > though this patch does not change any behaviour and is used > currently by no > part of the publicly available Kannel, I'd like to have a vote on its > usablity and cleanliness for inclusion in the CVS. > > the main changes from the patch submitted by Rene is > reogranization of the > two > last if statements in find_entity() into an if..else > statement in order to > make gcc happy, and a change to html-entities.def to include > the '<','>' > and > '"' entities with decimal values. > > P.S. > the test_octstr_format detects two memory leaks - from first > look I didn't > understand what is causing them. could someone familiar with > code please > take > a look ? > > -- > Oded Arbel > m-Wise mobile solutions > > On Monday 23 September 2002 04:13, Rene Kluwen / Chimit > Software Solutions > wrote: > > Hello list, > > > > So I took my own challenge (I was bored ;]). > > (Sorry, I will try to stick with only one patch for the > same thing, next > > time I post it.) > > > > Advantages of this patch over the previous one: > > - It is faster, because it uses a binary search (didn't really bench > > mark it though). > > - It is less lines of code (so better to read and less > chance on bugs) > > - It doesn't rely on c-strings, except for the oct_str functions. > > - The oct_str functions are also used for comparing, hencing porting > > to other locales does not impose a problem. > > > > In principle, octstr_convert_to_html_entities could be made > as fast by > > binary searching the table as well. But it requires sorting > the table. > > If the compiler optimizes well enough (which it does), > generating the > > entities-table does not require cpu seconds at run-time. > > > > -- Rene... > > >
RE: [REPOST] [PATCH] emi2 reconnection behaviour
I'd suggest to set the default of retry as 'yes', as most users do use EMI over TCP/IP. --Oded Arbelm-Wise mobile solutions[EMAIL PROTECTED] +972-9-9581711 (116)+972-67-340014 ::.."Existence is not only temporary, it's pointless!" -- Calvin and Hobbes -Original Message-From: Angel Fradejas [mailto:[EMAIL PROTECTED]]Sent: Monday, September 23, 2002 4:13 PMTo: Andreas FinkCc: [EMAIL PROTECTED]Subject: RE: [REPOST] [PATCH] emi2 reconnection behaviour Ok, sounds reasonable for me. I didn't know that fact for Germany. So I can resubmit the patch, keeping the "retry" directive, with "no" as default (as it is actually), and fix the behaviour with a "reconnect-delay" directive, with a 10 seconds default. Is this ok? Angel. -Mensaje original-De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Andreas FinkEnviado el: lunes 23 de septiembre de 2002 13:44Para: Angel FradejasCC: [EMAIL PROTECTED]Asunto: Re: [REPOST] [PATCH] emi2 reconnection behaviourOn Montag, September 23, 2002, at 10:33 Uhr, Angel Fradejas wrote: >Somehow I disageee. Some folks use EMI/UCP on dialup links so you don't > want to have it retry all the time and open the link. >"It always assumes reconnection" is thus not a good idea. Then we could mark it as a compatibility-breaker in the next release. I think there are much more people using it over direct tcp links than dialup ones. This is definitively wrong for users in Germany as the german carriers don't allow connectivity over the internet usually but only over 2Mbps permanent leased line (very expensive) or ISDN dial-on demand dialup to a private network.I think we simply should fix the existing behaviour instead of inventing another new one.Andreas FinkGlobal Networks, Inc.--Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333Global Networks, Inc. Schwarzwaldallee 16, 4058 Basel, SwitzerlandWeb: http://www.global-networks.ch/ [EMAIL PROTECTED]--Member of the GSM Association
RE: Octstr support for converting to and from HTML 4 entities.
-Original Message-From: Andreas Fink [mailto:[EMAIL PROTECTED]]Sent: Monday, September 23, 2002 4:13 PMTo: Oded ArbelCc: [EMAIL PROTECTED]Subject: Re: Octstr support for converting to and from HTML 4 entities. Oh. that was me - sorry. its no hard rule, but basicly what I meant is - don't use c strings for doing complicated stuff that the Octstr sub system handles better and more safely. do use c-string library calls for simple stuff that the library call would do better, especially if the call doesnot modify the content of the string (hence - no risk for buffer overflows). for example, when you want to compare octstrings you can use strcmp(octstr_get_cstr( or you can use octstr_compare(). this is the border line case IMO, where in this case I would have used the octstr_compare() as it involves fewer calls. you have already demonstrated that you can choose correctly between complexity and safety, and you can make the same decisions here. most importantly - don't take anything said by Kannel developers , especially me, as hard truth - those are simply recomendations. if we hate your code so much (not that I do) - we can change when it is in the CVS :-) strcmp(octstr_get_cstr(... and octstr_compare() behave DIFFERENTLY. if I remember correctly octstr_compare is case sensitive where strcmp is more or less simply comparing the bytes. strcmp should be locale sensitive as per the POSIX standard, IIRC. it has nothing to do with case sensitivity. I wouldnt count on it to compare on upper/lowercase and even diacritical characters. Well - you should. on the contrary - while strcmp is (or at least should be) locale aware, octstr_compare() uses memcmp() internally, which does simple byte comparison. OTOH, octstr_str_compare() which IMO should behave no different then octstr_compare() uses strcmp() internally. as you can see comparing strings is not always obvious. but it should be at least consistent. So if you can write a parameter in a config file in upper or lower case and it doesn't really matter, suddendly using strcmp would make the behaviour really strange. if you want to be case insensitive, you can use stricmp() or octstr_case_compare(). since Rene uses octstr_str_compare() which internally uses the locale sensitive strcmp(), maybe we should change it to use octstr_compare() somehow so that comparison would be byte ordered (locale insensitive) and sort the entity list to match ? octstr.c is an abstraction layer. Thats what it is there for. So use it for that purpose. and frankly, the memory checking stuff is really useful in it. I'm fixing a few dozen memory leaks by using it. It points with the finger to it all the time. Very easy to fix this way. stdc sting.h stuff doesn't give you any of that. That's why its always a good idea to use it. sometimes though, if you are careful, the std lib calls provide extra performance which is also important. --Oded Arbelm-Wise mobile solutions[EMAIL PROTECTED] +972-9-9581711 (116)+972-67-340014 ::..If you don't care where you are, then you ain't lost.
Re:[PATCH] Octstr support for converting to and from HTML 4 entities.
1.
Don't forget to include the octstr_insert_char patch either.
This code won't work without it (the patch). I do not believe any code that
uses it works as it is now.
(a quick grep yielded that indeed there is no code, using it atm).
2.
test_octstr_format: Where can I find this function?
- Original Message -
Date: Mon September 23, 2002 04:55 PM
From: Oded Arbel <[EMAIL PROTECTED]>
To: Kannel-devel (E-mail) <[EMAIL PROTECTED]>
Subject: [PATCH] Octstr support for converting to and from HTML 4 entities.
Hi list.
Here's the full HTML entity patch based on the work of Rene Kluwen
(Thanks !)
I only tested it to work as expected (both 'to' and 'from') and that no
memory leaks are present - have not benchmarked it, but I think that the
code
by Rene should prove much faster then my original hack.
though this patch does not change any behaviour and is used currently by no
part of the publicly available Kannel, I'd like to have a vote on its
usablity and cleanliness for inclusion in the CVS.
the main changes from the patch submitted by Rene is reogranization of the
two
last if statements in find_entity() into an if..else statement in order to
make gcc happy, and a change to html-entities.def to include the '<','>'
and
'"' entities with decimal values.
P.S.
the test_octstr_format detects two memory leaks - from first look I didn't
understand what is causing them. could someone familiar with code please
take
a look ?
--
Oded Arbel
m-Wise mobile solutions
On Monday 23 September 2002 04:13, Rene Kluwen / Chimit Software Solutions
wrote:
> Hello list,
>
> So I took my own challenge (I was bored ;]).
> (Sorry, I will try to stick with only one patch for the same thing, next
> time I post it.)
>
> Advantages of this patch over the previous one:
> - It is faster, because it uses a binary search (didn't really bench
> mark it though).
> - It is less lines of code (so better to read and less chance on bugs)
> - It doesn't rely on c-strings, except for the oct_str functions.
> - The oct_str functions are also used for comparing, hencing porting
> to other locales does not impose a problem.
>
> In principle, octstr_convert_to_html_entities could be made as fast by
> binary searching the table as well. But it requires sorting the table.
> If the compiler optimizes well enough (which it does), generating the
> entities-table does not require cpu seconds at run-time.
>
> -- Rene...
--- gwlib/octstr.h 2002-09-04 20:42:57.0 +0300
+++ gwlib/octstr.h 2002-09-22 20:44:43.0 +0300
@@ -582,4 +582,17 @@
*/
int octstr_recode (Octstr *tocode, Octstr *fromcode, Octstr *orig);
+/*
+ * make data HTML safe by converting appropriate characters to HTML entities.
+ * conversion is done in place
+ */
+void octstr_convert_to_html_entities(Octstr* input);
+
+/*
+ * convert HTML safe data back to binary data by replacing HTML entities with their
+ * respective character values.
+ * conversion is done in place
+ */
+void octstr_convert_from_html_entities(Octstr* input);
+
#endif
--- gwlib/octstr.c 2002-09-23 16:13:13.0 +0300
+++ gwlib/octstr.c 2002-09-23 16:37:40.0 +0300
@@ -2181,3 +2182,95 @@
return resultcode;
}
+
+/*
+ * function octstr_convert_to_html_entities()
+ * make data HTML safe by converting appropriate characters to HTML entities
+ * Input: data to be inserted in HTML
+ **/
+void octstr_convert_to_html_entities(Octstr* input)
+{
+int i;
+
+for (i = 0; i < octstr_len(input); ++i) {
+switch (octstr_get_char(input, i)) {
+#define ENTITY(a,b) \
+case a: \
+octstr_delete(input, i, 1); \
+octstr_insert(input, octstr_imm("&" b ";"), i); \
+i += sizeof(b); break;
+#include "gwlib/html-entities.def"
+#undef ENTITY
+}
+}
+}
+
+/*
+ * This function is meant to find html entities in an octstr.
+ * The html-entities.def file must be sorted alphabetically for
+ * this function to work (according to current Locale in use).
+*/
+static int octstr_find_entity(Octstr* input, int startfind, int endfind)
+{
+#define ENTITY(a,b) { a, b },
+struct entity_struct {
+int entity;
+char *entity_str;
+};
+const struct entity_struct entities[] = {
+#include "html-entities.def"
+{ -1, "" } /* pivot */
+};
+#undef ENTITY
+int center; /* position in table that we are about to compare */
+int matchresult;/* result of match agains found entity name. indicates less, equal or greater */
+
+if (endfind == 0) {
+/* when calling this function we do not (nor even want to) know the
+ * sizeof(entities). Hence this check. */
+endfind = (sizeof(entities) / sizeof(struct entity_struct)) - 1;
+}
+center = startfind + ((endfind - startfind) / 2);
+matchresult = octstr_str_compare(input, entities[center].entity_str);
+if (matchresult == 0) {
+return entities[center].entity;
+}
+if (endfind - startfind <= 1) {
+/* we are a
RE: [REPOST] [PATCH] emi2 reconnection behaviour
Ok, sounds reasonable for me. I didn't know that fact for Germany. So I can resubmit the patch, keeping the "retry" directive, with "no" as default (as it is actually), and fix the behaviour with a "reconnect-delay" directive, with a 10 seconds default. Is this ok? Angel. -Mensaje original-De: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]En nombre de Andreas FinkEnviado el: lunes 23 de septiembre de 2002 13:44Para: Angel FradejasCC: [EMAIL PROTECTED]Asunto: Re: [REPOST] [PATCH] emi2 reconnection behaviourOn Montag, September 23, 2002, at 10:33 Uhr, Angel Fradejas wrote: >Somehow I disageee. Some folks use EMI/UCP on dialup links so you don't > want to have it retry all the time and open the link. >"It always assumes reconnection" is thus not a good idea. Then we could mark it as a compatibility-breaker in the next release. I think there are much more people using it over direct tcp links than dialup ones. This is definitively wrong for users in Germany as the german carriers don't allow connectivity over the internet usually but only over 2Mbps permanent leased line (very expensive) or ISDN dial-on demand dialup to a private network.I think we simply should fix the existing behaviour instead of inventing another new one.Andreas FinkGlobal Networks, Inc.--Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333Global Networks, Inc. Schwarzwaldallee 16, 4058 Basel, SwitzerlandWeb: http://www.global-networks.ch/ [EMAIL PROTECTED]--Member of the GSM Association
Re: Octstr support for converting to and from HTML 4 entities.
Oh. that was me - sorry. its no hard rule, but basicly what I meant is - don't use c strings for doing complicated stuff that the Octstr sub system handles better and more safely. do use c-string library calls for simple stuff that the library call would do better, especially if the call doesnot modify the content of the string (hence - no risk for buffer overflows). for example, when you want to compare octstrings you can use strcmp(octstr_get_cstr( or you can use octstr_compare(). this is the border line case IMO, where in this case I would have used the octstr_compare() as it involves fewer calls. you have already demonstrated that you can choose correctly between complexity and safety, and you can make the same decisions here. most importantly - don't take anything said by Kannel developers , especially me, as hard truth - those are simply recomendations. if we hate your code so much (not that I do) - we can change when it is in the CVS :-) strcmp(octstr_get_cstr(... and octstr_compare() behave DIFFERENTLY. if I remember correctly octstr_compare is case sensitive where strcmp is more or less simply comparing the bytes. I wouldnt count on it to compare on upper/lowercase and even diacritical characters. Think of this: ä is a german umlaut. to sort ä in german books, its sorted like "a". but it can also be written as "ae". now is ä = a or ä > a or ä < a? how about Ae (swiss way of writing capital ä)? how about ß which is replaced as "ss"? as you can see comparing strings is not always obvious. but it should be at least consistent. So if you can write a parameter in a config file in upper or lower case and it doesn't really matter, suddendly using strcmp would make the behaviour really strange. octstr.c is an abstraction layer. Thats what it is there for. So use it for that purpose. and frankly, the memory checking stuff is really useful in it. I'm fixing a few dozen memory leaks by using it. It points with the finger to it all the time. Very easy to fix this way. stdc sting.h stuff doesn't give you any of that. Andreas Fink Global Networks, Inc. -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Global Networks, Inc. Schwarzwaldallee 16, 4058 Basel, Switzerland Web: http://www.global-networks.ch/ [EMAIL PROTECTED] -- Member of the GSM Association
Re: Octstr support for converting to and from HTML 4 entities.
> For two functions ? doesn't sound like a good idea to me. I think it should be part >of the Octstr system as are the base64 encoding and url encoding routines (for >example). Oh, ok then. Haven't seen that there are only two functions. That's ok with me then. Stipe [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 --- wapme.net - wherever you are
[PATCH] Octstr support for converting to and from HTML 4 entities.
Hi list.
Here's the full HTML entity patch based on the work of Rene Kluwen (Thanks !)
I only tested it to work as expected (both 'to' and 'from') and that no
memory leaks are present - have not benchmarked it, but I think that the code
by Rene should prove much faster then my original hack.
though this patch does not change any behaviour and is used currently by no
part of the publicly available Kannel, I'd like to have a vote on its
usablity and cleanliness for inclusion in the CVS.
the main changes from the patch submitted by Rene is reogranization of the two
last if statements in find_entity() into an if..else statement in order to
make gcc happy, and a change to html-entities.def to include the '<','>' and
'"' entities with decimal values.
P.S.
the test_octstr_format detects two memory leaks - from first look I didn't
understand what is causing them. could someone familiar with code please take
a look ?
--
Oded Arbel
m-Wise mobile solutions
On Monday 23 September 2002 04:13, Rene Kluwen / Chimit Software Solutions
wrote:
> Hello list,
>
> So I took my own challenge (I was bored ;]).
> (Sorry, I will try to stick with only one patch for the same thing, next
> time I post it.)
>
> Advantages of this patch over the previous one:
> - It is faster, because it uses a binary search (didn't really bench
> mark it though).
> - It is less lines of code (so better to read and less chance on bugs)
> - It doesn't rely on c-strings, except for the oct_str functions.
> - The oct_str functions are also used for comparing, hencing porting
> to other locales does not impose a problem.
>
> In principle, octstr_convert_to_html_entities could be made as fast by
> binary searching the table as well. But it requires sorting the table.
> If the compiler optimizes well enough (which it does), generating the
> entities-table does not require cpu seconds at run-time.
>
> -- Rene...
--- gwlib/octstr.h 2002-09-04 20:42:57.0 +0300
+++ gwlib/octstr.h 2002-09-22 20:44:43.0 +0300
@@ -582,4 +582,17 @@
*/
int octstr_recode (Octstr *tocode, Octstr *fromcode, Octstr *orig);
+/*
+ * make data HTML safe by converting appropriate characters to HTML entities.
+ * conversion is done in place
+ */
+void octstr_convert_to_html_entities(Octstr* input);
+
+/*
+ * convert HTML safe data back to binary data by replacing HTML entities with their
+ * respective character values.
+ * conversion is done in place
+ */
+void octstr_convert_from_html_entities(Octstr* input);
+
#endif
--- gwlib/octstr.c 2002-09-23 16:13:13.0 +0300
+++ gwlib/octstr.c 2002-09-23 16:37:40.0 +0300
@@ -2181,3 +2182,95 @@
return resultcode;
}
+
+/*
+ * function octstr_convert_to_html_entities()
+ * make data HTML safe by converting appropriate characters to HTML entities
+ * Input: data to be inserted in HTML
+ **/
+void octstr_convert_to_html_entities(Octstr* input)
+{
+int i;
+
+for (i = 0; i < octstr_len(input); ++i) {
+switch (octstr_get_char(input, i)) {
+#define ENTITY(a,b) \
+case a: \
+octstr_delete(input, i, 1); \
+octstr_insert(input, octstr_imm("&" b ";"), i); \
+i += sizeof(b); break;
+#include "gwlib/html-entities.def"
+#undef ENTITY
+}
+}
+}
+
+/*
+ * This function is meant to find html entities in an octstr.
+ * The html-entities.def file must be sorted alphabetically for
+ * this function to work (according to current Locale in use).
+*/
+static int octstr_find_entity(Octstr* input, int startfind, int endfind)
+{
+#define ENTITY(a,b) { a, b },
+struct entity_struct {
+int entity;
+char *entity_str;
+};
+const struct entity_struct entities[] = {
+#include "html-entities.def"
+{ -1, "" } /* pivot */
+};
+#undef ENTITY
+int center; /* position in table that we are about to compare */
+int matchresult;/* result of match agains found entity name. indicates less, equal or greater */
+
+if (endfind == 0) {
+/* when calling this function we do not (nor even want to) know the
+ * sizeof(entities). Hence this check. */
+endfind = (sizeof(entities) / sizeof(struct entity_struct)) - 1;
+}
+center = startfind + ((endfind - startfind) / 2);
+matchresult = octstr_str_compare(input, entities[center].entity_str);
+if (matchresult == 0) {
+return entities[center].entity;
+}
+if (endfind - startfind <= 1) {
+/* we are at the end of our results */
+return -1;
+}
+if (matchresult < 0) {
+/* keep searching in first part of the table */
+return octstr_find_entity(input, startfind, center);
+} else {
+/* keep searching in last part of the table */
+return octstr_find_entity(input, center, endfind);
+}
+}
+
+/*
+ * function octstr_convert_from_html_entities()
+ * convert HTML safe data back to binary data by replacing HTML entities with their
+ * respective character values
+ * Input:
RE: CMTI patch
Copy cmti_patch.udiff in the root directory of your gateway sources (e.g. de gateway directory). And type: patch -p0 < cmti_patch.udiff. Probably, it will work best if you have the CVS version of the sources. Location of files has been changed over the sources that you can download as .tar. -- Rene... - Original Message - Date: Mon September 23, 2002 03:42 PM From: Avner Sternheim <[EMAIL PROTECTED]> To: Stipe Tolj <[EMAIL PROTECTED]>, Avner Sternheim <[EMAIL PROTECTED]> cc: [EMAIL PROTECTED] Subject: RE: CMTI patch How can I use the patch to my Kannel ? -Original Message- From: Stipe Tolj [mailto:[EMAIL PROTECTED]] Sent: Sunday, September 22, 2002 7:01 PM To: Avner Sternheim Cc: [EMAIL PROTECTED] Subject: Re: CMTI patch > So, (just to be sure ) does the current AT2 driver in the KANNEL CVS include > the CMTI patch ? you can check always current changes of cvs tree via the viewcvs interface from the web site. Stipe [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 --- wapme.net - wherever you are
RE: Octstr support for converting to and from HTML 4 entities.
> -Original Message- > From: Stipe Tolj [mailto:[EMAIL PROTECTED]] > > We needed the ability to encode data to XML/HTML with HTML > 4 entities as defined by W3C, so I thought that adding it to > the Octstr infrastructure would be nice - so that other > people will be able to use it. > > > > So here it is for your review - don't spare the ammo. > > why not. But how about not incorporting this directly to the octstr > module but have an own source file then?! For two functions ? doesn't sound like a good idea to me. I think it should be part of the Octstr system as are the base64 encoding and url encoding routines (for example). -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. Never knock on Death's door. Ring the bell and run! Death hates that.
RE: Octstr support for converting to and from HTML 4 entities.
> -Original Message- > From: Rene Kluwen [mailto:[EMAIL PROTECTED]] > > strlen() does it faster. > > > I am making an immutable octetstring, just for the sake of > not having to > use strlen. Since I got commented before that the string > functions in C > were a bad thing. There was no other reason. Change at will. Oh. that was me - sorry. its no hard rule, but basicly what I meant is - don't use c strings for doing complicated stuff that the Octstr sub system handles better and more safely. do use c-string library calls for simple stuff that the library call would do better, especially if the call doesnot modify the content of the string (hence - no risk for buffer overflows). for example, when you want to compare octstrings you can use strcmp(octstr_get_cstr( or you can use octstr_compare(). this is the border line case IMO, where in this case I would have used the octstr_compare() as it involves fewer calls. you have already demonstrated that you can choose correctly between complexity and safety, and you can make the same decisions here. most importantly - don't take anything said by Kannel developers , especially me, as hard truth - those are simply recomendations. if we hate your code so much (not that I do) - we can change when it is in the CVS :-) -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. X windows: Putting new limits on productivity.
RE: DLR receipts <---> sms sent
-Original Message-From: Andreas Fink [mailto:[EMAIL PROTECTED]] when you deliver the ticket you ask for a delivery report and you simply include &id= as constant string. Of course you replace with whatever "ticket" number you use. The important thing here is that you have to actively PUSH the message to kannel. You can not PULL for it as there is no X-Kannel-DLRMASK or X-Kannel-DLRURL header (yet?). No ? oops. so forget about what I said in my previous message. sorry. --Oded Arbelm-Wise mobile solutions[EMAIL PROTECTED] +972-9-9581711 (116)+972-67-340014 ::..Even if you do learn to speak correct English, whom are you going to speakit to? -- Clarence Darrow
RE: CMTI patch
How can I use the patch to my Kannel ? -Original Message- From: Stipe Tolj [mailto:[EMAIL PROTECTED]] Sent: Sunday, September 22, 2002 7:01 PM To: Avner Sternheim Cc: [EMAIL PROTECTED] Subject: Re: CMTI patch > So, (just to be sure ) does the current AT2 driver in the KANNEL CVS include > the CMTI patch ? you can check always current changes of cvs tree via the viewcvs interface from the web site. Stipe [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 --- wapme.net - wherever you are
Re: DLR receipts <---> sms sent
Thanks a lot. Makes full sense. The relevant X-Kannel-Headers exists, at least as per 1.2.0 document. P. --- Andreas Fink <[EMAIL PROTECTED]> wrote: > > On Montag, September 23, 2002, at 12:37 Uhr, Kita > B. Ndara wrote: > > > No, this would not achieve what I want. Consider > for > > instance that I have a service whereby a user > requests > > a ticket number via sms. I want to know the user > got > > his ticket. So the ID is per message, not per > service. > > > > > > One solution: Does the dlrurl take the %a param? > That > > is, can I see the message that is being reported > on? > > If so then I won't need the ID. > > > > P. > > > > when you deliver the ticket you ask for a delivery > report and > you simply include &id= as constant string. Of > course you replace > with whatever "ticket" number you use. The > important thing here is > that you have to actively PUSH the message to > kannel. You can not PULL > for it as there is no X-Kannel-DLRMASK or > X-Kannel-DLRURL header > (yet?). So you would get the request to your > application and reply > nothing. then your application creates a push > request with that > constant &id=... and you will get called back with > exactly this &id=... > so you know which one has been delivered > > > Andreas Fink > Global Networks, Inc. > > -- > Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: > +41-79-2457333 > Global Networks, Inc. Schwarzwaldallee 16, 4058 > Basel, Switzerland > Web: http://www.global-networks.ch/ > [EMAIL PROTECTED] > -- > Member of the GSM Association > __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
RE: DLR receipts <---> sms sent
> -Original Message- > From: Kita B. Ndara [mailto:[EMAIL PROTECTED]] > No, this would not achieve what I want. Consider for > instance that I have a service whereby a user requests > a ticket number via sms. I want to know the user got > his ticket. So the ID is per message, not per service. That's what I meant. you probably set the dlr-url as static in the service configuration. this is not the way to go. I meant to set the dlr-url per message in the send-sms interface using a GET parameter or with a HTTP header in an sms-service reply. > One solution: Does the dlrurl take the %a param? That > is, can I see the message that is being reported on? > If so then I won't need the ID. yes - dlrurl accepts a %a paremeter for the "message data", but the message data of a dlr-url is not the content of the original message (which cannot be retrieved using most service and is not kept in persistant storage) but some kind of textual description generated by the driver - often the actuall result code from the SMSC. -- Oded Arbel m-Wise mobile solutions [EMAIL PROTECTED] +972-9-9581711 (116) +972-67-340014 ::.. Reality is that which, when you stop believing in it, doesn't go away. -- Phillip K. Dick, 1928-1982 > --- Oded Arbel <[EMAIL PROTECTED]> wrote: > > > Its not in the docs, but is otherwise obvious - > > embed your identifing parameter in the URL you > > submit to dlr-url, w/o kannel % parameter parsing. > > for example: > > dlrurl=http://myhnost/mycgi?myid=1234&result=%d > > > > -- > > Oded Arbel > > m-Wise mobile solutions > > [EMAIL PROTECTED] > > > > +972-9-9581711 (116) > > +972-67-340014 > > > > ::.. > > Aunty Entity: "Do you know who I was? Nobody. Except > > on the day after, > > I was still alive. This nobody had a chance to be > > somebody." > > -- from "Mad Max Beyond Thunderdome" > > > > > -Original Message- > > > From: Kita B. Ndara [mailto:[EMAIL PROTECTED]] > > > Sent: Friday, September 20, 2002 1:58 PM > > > To: [EMAIL PROTECTED] > > > Subject: DLR receipts <---> sms sent > > > > > > > > > Quick question: Each time I send an sms (either > > > through sendsms interface or via an sms service) > > and I > > > set the dlrmask, I want to be able to tag the > > message, > > > so that when the dlrurl is called, some cgi > > parameter > > > passed to it will tell me which message it relates > > to. > > > How do I do that? I've scanned the docs but nada. > > I'm > > > using v1.2.0 > > > > > > Thanks > > > > > > > > > __ > > > Do You Yahoo!? > > > Everything you'll ever need on one web page > > > from News and Sport to Email and Music Charts > > > http://uk.my.yahoo.com > > > > > > > > __ > Do You Yahoo!? > Everything you'll ever need on one web page > from News and Sport to Email and Music Charts > http://uk.my.yahoo.com >
Re: Octstr support for converting to and from HTML 4 entities.
> We needed the ability to encode data to XML/HTML with HTML 4 entities as defined by >W3C, so I thought that adding it to the Octstr infrastructure would be nice - so that >other people will be able to use it. > > So here it is for your review - don't spare the ammo. why not. But how about not incorporting this directly to the octstr module but have an own source file then?! BTW, haven't seen it yet, but will. Stipe [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 --- wapme.net - wherever you are
Re: SMSC-box?
Rene Kluwen / Chimit Software Solutions wrote: > > Hello devel, > > When reading the docs, I came upon a question. > Have there been thoughts about putting the smsc-interfaces into a > seperate box? > And then have the messages come in through a connector, the same way > as UDP datagrams come in? > True... I think in daily usage, most people use only 1 smsc. > But if requirements are lots of messages per minute. This feature > would add to scalability in terms of just putting more hardware. > > Just my 2 cts. BTW, we have 46 connections (various protocols, including SMPP, EMI/UCP, SMASI) on one bearerbox running ;) If you are in concern of handling more SMS per second in the scope of bearerbox, you may scale using Linux virtual server environments. IMO, bearerbox is a SMSC router and it's fine the way it is. Stipe [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 --- wapme.net - wherever you are
Re: DLR receipts <---> sms sent
On Montag, September 23, 2002, at 12:37 Uhr, Kita B. Ndara wrote: No, this would not achieve what I want. Consider for instance that I have a service whereby a user requests a ticket number via sms. I want to know the user got his ticket. So the ID is per message, not per service. One solution: Does the dlrurl take the %a param? That is, can I see the message that is being reported on? If so then I won't need the ID. P. when you deliver the ticket you ask for a delivery report and you simply include &id= as constant string. Of course you replace with whatever "ticket" number you use. The important thing here is that you have to actively PUSH the message to kannel. You can not PULL for it as there is no X-Kannel-DLRMASK or X-Kannel-DLRURL header (yet?). So you would get the request to your application and reply nothing. then your application creates a push request with that constant &id=... and you will get called back with exactly this &id=... so you know which one has been delivered Andreas Fink Global Networks, Inc. -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Global Networks, Inc. Schwarzwaldallee 16, 4058 Basel, Switzerland Web: http://www.global-networks.ch/ [EMAIL PROTECTED] -- Member of the GSM Association
Re: [REPOST] [PATCH] emi2 reconnection behaviour
On Montag, September 23, 2002, at 10:33 Uhr, Angel Fradejas wrote: >Somehow I disageee. Some folks use EMI/UCP on dialup links so you don't > want to have it retry all the time and open the link. >"It always assumes reconnection" is thus not a good idea. Then we could mark it as a compatibility-breaker in the next release. I think there are much more people using it over direct tcp links than dialup ones. This is definitively wrong for users in Germany as the german carriers don't allow connectivity over the internet usually but only over 2Mbps permanent leased line (very expensive) or ISDN dial-on demand dialup to a private network. I think we simply should fix the existing behaviour instead of inventing another new one. Andreas Fink Global Networks, Inc. -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Global Networks, Inc. Schwarzwaldallee 16, 4058 Basel, Switzerland Web: http://www.global-networks.ch/ [EMAIL PROTECTED] -- Member of the GSM Association
Re: FW: UCP protocol
On Montag, September 23, 2002, at 09:09 Uhr, Tronet Sarah wrote: Hi, Thanks for your contribution, it helps a lot. I still have two issues about this protocol: 1- You wrote" it simply waits for your session to connect " (in the second mode) , should I just connect or also open a session (using 60- message) each time I connect? Normally you would connect and log-in with a 60 message. 2- Is the UCP/EMI protocol only provided by CMG SMSC or is there other SMSC using this protocol? The EMI protocol was originally invented for paging system and adapted by CMG for SMS usage. The current EMI/UCP protocol is supported by CMG mainly but CMG is very popular amongst european operators. Our Message!Mover SMSC also supports a subset of the EMI/UCP protocol (everything Kannel needs without all the fancy stuff no one uses). Andreas Fink Global Networks, Inc. -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Global Networks, Inc. Schwarzwaldallee 16, 4058 Basel, Switzerland Web: http://www.global-networks.ch/ [EMAIL PROTECTED] -- Member of the GSM Association
Re: SMS relay
> I have a question that really need to be answered, can anyone help me? > Here's the question: > > Kannel(HTTP) -> Kannel(SMPP) -> SMSC > > I have a friend using kannel and using http to send sms to me. I am a middle > man, so the question is how do I get the SMS content and dump to an SMPP > SMSC. Do i need to rewrite anything or add a patch in kannel source, or is > there any way I can do it? I read the userguide, but doesn't go into it > extensively. > > Your help is very much appreciated, and sorry for being such a pain. either provide your frind a kannel sendsms-user account inside your kannel configuration directly or let your friend run an "own" Kannel instance and access your Kannel instance via the smsc_http SMSC type that connects his bearerbox to your smsbox. Stipe [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 --- wapme.net - wherever you are
Re: CMTI patch
> So, (just to be sure ) does the current AT2 driver in the KANNEL CVS include > the CMTI patch ? you can check always current changes of cvs tree via the viewcvs interface from the web site. Stipe [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 --- wapme.net - wherever you are
RE: DLR receipts <---> sms sent
No, this would not achieve what I want. Consider for instance that I have a service whereby a user requests a ticket number via sms. I want to know the user got his ticket. So the ID is per message, not per service. One solution: Does the dlrurl take the %a param? That is, can I see the message that is being reported on? If so then I won't need the ID. P. --- Oded Arbel <[EMAIL PROTECTED]> wrote: > > Its not in the docs, but is otherwise obvious - > embed your identifing parameter in the URL you > submit to dlr-url, w/o kannel % parameter parsing. > for example: > dlrurl=http://myhnost/mycgi?myid=1234&result=%d > > -- > Oded Arbel > m-Wise mobile solutions > [EMAIL PROTECTED] > > +972-9-9581711 (116) > +972-67-340014 > > ::.. > Aunty Entity: "Do you know who I was? Nobody. Except > on the day after, > I was still alive. This nobody had a chance to be > somebody." > -- from "Mad Max Beyond Thunderdome" > > > -Original Message- > > From: Kita B. Ndara [mailto:[EMAIL PROTECTED]] > > Sent: Friday, September 20, 2002 1:58 PM > > To: [EMAIL PROTECTED] > > Subject: DLR receipts <---> sms sent > > > > > > Quick question: Each time I send an sms (either > > through sendsms interface or via an sms service) > and I > > set the dlrmask, I want to be able to tag the > message, > > so that when the dlrurl is called, some cgi > parameter > > passed to it will tell me which message it relates > to. > > How do I do that? I've scanned the docs but nada. > I'm > > using v1.2.0 > > > > Thanks > > > > > > __ > > Do You Yahoo!? > > Everything you'll ever need on one web page > > from News and Sport to Email and Music Charts > > http://uk.my.yahoo.com > > > > __ Do You Yahoo!? Everything you'll ever need on one web page from News and Sport to Email and Music Charts http://uk.my.yahoo.com
Re: Octstr support for converting to and from HTML 4 entities.
You are write about the looping for ever - I actually didn't test the convert_from code (silly me :-) mostly as I don't use it (yet), but I should have tested it anyway. I'll rewrite it. On Monday 23 September 2002 02:36, Rene Kluwen / Chimit Software Solutions wrote: > In your html-entities.def I happened to notice that & was missing! > I don't know if that is on purpose, but if not: now you know ;) No - its not on purpose. I created the def from an entity decleration DTD I found on w3c's site which contained only the high range entities. I later added the missing 4 low range entities - & " > and <. It'll be included in the resubmission. thanks for noticing. > Anyhow... I came up with a faster version. That depends on > html-entities.def being sorted on entity-name. Thats is very nice. it does improve (heck - its a rewrite :-) on the what I wrote, and the convert_from() is very clean as I like it - but I do have some comments on the find_entiry(): - The sorting is not locale dependant, but character odinal value dependant - which is better, I think. - I didn't understand this : octstr_len(octstr_imm((entities[loop].entity_str))) except from some extra parenthesis, you are convering a c-string to octstr just to get its length ? strlen() does it faster. > About being readable: the use of macro's and including an external > file keeps being questionable to me as far as readability is > concerned. I can relate to that point of view, but it is tidy :-) > But attached version is more efficient indeed. It uses the macro's in > html-entities.def as well. But I tried to explain as much as possible > in comments. All in all - good looking piece of code. I'd like to reintegrate that into the patch, but modify the find_entity() a bit (reordering instructions mostly). may I ? -- Oded Arbel m-Wise mobile solutions
RE: 6310i 7650 problems..
I have tried the force-sar= true and force-sar =yes and they both don't work.. The content I am trying to get is a simple wap page so I am sure it's not too big.. in addition to this I have added to sar patches that were posted on the list.. both of them.. Is there something I am missing..?? Thank you, Maria -Original Message- From: Stipe Tolj [mailto:[EMAIL PROTECTED]] Sent: 19 September 2002 12:13 To: Maria Turk Cc: [EMAIL PROTECTED] Subject: Re: 6310i 7650 problems.. > and on the 7650 I am not getting anything.. > > is there something special in the configuration that I have missed yep, the 7650 uses SARed requests. Kannel does not support SARed request currently. But Aarno and we here at Wapme are having SARed versions that are to be incorporated to the official source tree in some time. Meanwhile you may use the 'force-sar = yes' directive in the wapbox config group. This will let wapbox respond to the 7650 even in non-SARed responses, which does work, at least if the content is not so big that it really should have been segmented. Stipe [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 --- wapme.net - wherever you are
RE: [REPOST] [PATCH] emi2 reconnection behaviour
>Somehow I disageee. Some folks use EMI/UCP on dialup links so you don't > want to have it retry all the time and open the link. >"It always assumes reconnection" is thus not a good idea. Then we could mark it as a compatibility-breaker in the next release. I think there are much more people using it over direct tcp links than dialup ones. Angel FradejasMediafusión España, S.A.[EMAIL PROTECTED]www.mediafusion.esTel. +34 91 252 32 00Fax +34 91 572 27 08
Load testing of the Kannel
Hi, What is the maximum number of threads and the maximum size of the queue that can be specified in "bb.h" ? I am interested in testing the performance of the SMS gateway on very high loads. What can be the ideal test environment? What all factors are to be considered while performing such a test? Thanx and Regards, Vivek
Re: Packing User Agent Header.
On Saturday, September 21, 2002, at 04:02 PM, Nigar Sultana wrote:
> Hello All
>
> i want to have few clarification regarding the kannel wap gateway.
> Listing out them:
>
> 1>#define PDU(name, docstring, fields, is_valid) struct name { fields
> } name;
> what does this declaration means. we were not able to understand it.
This defines the structure itself. When called with PDU(something) you
get after the
expansion:
struct something {
fields
} something;
Then (conceptually) fields is expanded.
It may help to use gcc -E (or whatever option indicates precompiling
only in your
compiler).
>
> 2>In the Get request header portion we have added the User Agent Name
> and Value,
> The User-agent:0x29
> The Value can be either Nokia or Ericsson
> Wap box is throwing an error: "Error parsing application-header" what
> might be the problem.
This is because value should be a text string. Grab User-Agent headers
your phone is
sending or try using any text string as a value.
Aarno
