RE: The future of the project: Was: [RFC] mysql interface to kannel?
I would support such a decision. It's a serious problem right now, that this project has no real leadership. Even a temporary solution would be preferable. But, that being said, a meeting about the future of Kannel should be arranged as well, in the near future. Maybe even an irc meeting would do (of course a real meeting would be preferable, it would be considerably easier to make solid decisions). Is anyone on the list able to host such a meeting? Christian. -Original Message- From: Tuomas Luttinen Sent: to 26-07-2001 17:54 To: '[EMAIL PROTECTED] ' Cc: Subject:The future of the project: Was: [RFC] mysql interface to kannel? Jörg Pommnitz wrote: > My main concern is that there is currently no overall > architecture development and review in place. There is > nobody to slap peoples wrists and weed out short term > hacks for the benefit of a long term architecture. > Currently everything goes which is a clear path to > unmaintainability. Eric S. Raimonds papers on the Open > Source development process clearly demonstrate the > need for a clearing authority that has a clear vision > of the future of the system (e.g. a "Linus/Lars"). > In my view this is the most pressing need. Releases > are just numbers, but a broken architecture might kill > the project. You are right about this indeed. We have now lost Lars and Richard who would have suited into this position. Kalle seems to have too much other things to do to take the responcibility for the hole project. So my short term solution proposal is that we put up a three person junta to guide the project which means slapping people on their wrists, judging on the proposed solutions, ideas etc, granting CVS accesses and other things that keeping this project on its tracks needs. I came up with two persons to start with: bearerbox: Kalle wapbox:Aarno smsbox:? So the persons above are members of the original Kannel team, they know the code and the current architecture. I hope that Kalle would have time to look over bearerbox; it has been quiet on that part lately. The problem is the SMS side of the kannel: on this area there have been very windy lately and there is no original Kannel team members left to fill up the gap. So is there anyone out there with lot of experience with the smsbox, at least a some kind of a vision what our different SMS protocol modules currently have and what parts in them are the ones needing most attention? Joerg? And remember, this is really a temporary solution. I hope that the situation will change in the future and we could have a gateway architect again. He might be one of those three or just somebody else, put to his place by the Foundation or the developer community. This is because of the clear reason that the junta must communicate about the biggest solutions that affect more or less the hole Kannel which might hinder the decision making capability. So, how about some comments? -- Tuomas Luttinen Application Developer -- Reach U **
The future of the project: Was: [RFC] mysql interface to kannel?
Jörg Pommnitz wrote: > My main concern is that there is currently no overall > architecture development and review in place. There is > nobody to slap peoples wrists and weed out short term > hacks for the benefit of a long term architecture. > Currently everything goes which is a clear path to > unmaintainability. Eric S. Raimonds papers on the Open > Source development process clearly demonstrate the > need for a clearing authority that has a clear vision > of the future of the system (e.g. a "Linus/Lars"). > In my view this is the most pressing need. Releases > are just numbers, but a broken architecture might kill > the project. You are right about this indeed. We have now lost Lars and Richard who would have suited into this position. Kalle seems to have too much other things to do to take the responcibility for the hole project. So my short term solution proposal is that we put up a three person junta to guide the project which means slapping people on their wrists, judging on the proposed solutions, ideas etc, granting CVS accesses and other things that keeping this project on its tracks needs. I came up with two persons to start with: bearerbox: Kalle wapbox:Aarno smsbox:? So the persons above are members of the original Kannel team, they know the code and the current architecture. I hope that Kalle would have time to look over bearerbox; it has been quiet on that part lately. The problem is the SMS side of the kannel: on this area there have been very windy lately and there is no original Kannel team members left to fill up the gap. So is there anyone out there with lot of experience with the smsbox, at least a some kind of a vision what our different SMS protocol modules currently have and what parts in them are the ones needing most attention? Joerg? And remember, this is really a temporary solution. I hope that the situation will change in the future and we could have a gateway architect again. He might be one of those three or just somebody else, put to his place by the Foundation or the developer community. This is because of the clear reason that the junta must communicate about the biggest solutions that affect more or less the hole Kannel which might hinder the decision making capability. So, how about some comments? -- Tuomas Luttinen Application Developer -- Reach U **
AW: [RFC] mysql interface to kannel?
My main concern is that there is currently no overall architecture development and review in place. There is nobody to slap peoples wrists and weed out short term hacks for the benefit of a long term architecture. Currently everything goes which is a clear path to unmaintainability. Eric S. Raimonds papers on the Open Source development process clearly demonstrate the need for a clearing authority that has a clear vision of the future of the system (e.g. a "Linus/Lars"). In my view this is the most pressing need. Releases are just numbers, but a broken architecture might kill the project. Regards Joerg > -Ursprüngliche Nachricht- > Von: Stipe Tolj [mailto:[EMAIL PROTECTED]] > Gesendet am: Donnerstag, 26. Juli 2001 12:36 > Cc: '[EMAIL PROTECTED] ' > Betreff: Re: [RFC] mysql interface to kannel? > > > > PS: who controls Kannel releases now? > > > > > > > Good question. That's why I said we need either a new > > gateway architect, a stearing commitee/core group or the > > Kannel foundation. > > and it should be formed quite soon, so we can role out the latest > developments into development releases. > > Have there been any discussions on what steps a foundation > establishment would take? > > Regards, > Stipe > > [EMAIL PROTECTED] > --- > Wapme Systems AG > > Münsterstr. 248 > 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: [RFC] mysql interface to kannel?
> > PS: who controls Kannel releases now? > > > > Good question. That's why I said we need either a new > gateway architect, a stearing commitee/core group or the > Kannel foundation. and it should be formed quite soon, so we can role out the latest developments into development releases. Have there been any discussions on what steps a foundation establishment would take? Regards, Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 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: [RFC] mysql interface to kannel?
Howdy, > PS: who controls Kannel releases now? Nobody :-> I suggest at the moment, we run it by committee, unless someone wants to volunteer to be in charge of releases. I haven't dug through the scripts to work out how a "release" actually works, beyond sticking a label on the relevant versions... I'm open to suggestions, though. See ya, Nick -- Nick Clarey, System Architect| "Sometimes when you fill a vacuum, 3G LAB | it still sucks." - Rob Pike ph 44-1223-478900 fax 44-1223-478901 |
Re: [RFC] mysql interface to kannel?
Paul Keogh wrote: > > Note the absence of WAP. If anybody actually cares about WAP, the WAP > > components should be taken out and recast as a discrete product. The > > original premise that WAP and SMS sit within a common stack > > is not likely to > > happen in the real world, and I sense that the two differing > > applications of > > Kannel are tripping over each other. > > > > I'd guess that SMS is going to be the primary bearer for WAP > push in the short to mid term, given all the confusion about > how the GPRS/IP/operator technical and business mixture is > going to work. So it probably *will* be useful to maintain > the SMS and WAP code bases along common lines. There is empirical eveidence for this, it is, actual phoes working this way. Aarno
RE: [RFC] mysql interface to kannel?
> Note the absence of WAP. If anybody actually cares about WAP, the WAP > components should be taken out and recast as a discrete product. The > original premise that WAP and SMS sit within a common stack > is not likely to > happen in the real world, and I sense that the two differing > applications of > Kannel are tripping over each other. > I'd guess that SMS is going to be the primary bearer for WAP push in the short to mid term, given all the confusion about how the GPRS/IP/operator technical and business mixture is going to work. So it probably *will* be useful to maintain the SMS and WAP code bases along common lines.
RE: [RFC] mysql interface to kannel?
> > PS: who controls Kannel releases now? > Good question. That's why I said we need either a new gateway architect, a stearing commitee/core group or the Kannel foundation. Regards Joerg
RE: [RFC] mysql interface to kannel?
On Fri, 20 Jul 2001, Paul Keogh wrote: > > - logging facility: access.log data may be stored to mysql db, > > especialy for automatic billing support. > > - configuration facility: multi-groups like sms-user, sms-service, > > ota-config may be stored in mysql db, so there may be added or > > manipulated while runtime and the service would not have to be > > restarted to get notice of an update. This would make thinks > > particular slower, but may add incredible functionality gains. > > > > I think the DB interface would be quite useful but I would echo comments > from a previous post to ensure that there is a gw_ style wrapper approach > so that use is optional. > > Updating running configurations is much tricky and doesn't depend > on holding the configuration in a DB. There was some discussion > lead by Lars some time ago about doing this so the archives > might hold some interesting comments. Unfortunately, all Kannel > code assumes that config file is read once at start-up and would > require major surgery to move to a dynamic model. My custom tests can handle reload of configuration files via HTTP administration interfaces. For sendsms-users and sms-services, it does it 'on fly', but for other groups it restarts Kannel (which also can now be done via HTTP, i.e. without external start/stop script). Even for those groups which can be dynamically loaded it currently means: - lock system down - reload - release system In any case, it is something and usable for most needs, and can be tweaked quite easily (just split reloading into small parts), I just have had no time to do that yet. However, alas, it is based on that modification I did that smsbox is now merged to bearerbox etc. i.e. quite drastic modifications. So I simply cannot send a patch. (I have also replaced urltrans with own modules for sms-services and sendsms-users as they are practically different thing and removed some things rarely used and making things complicated) But a database interface in serial to http:, fixed-text: and file: is a very interesting idea. In any case, as soon as I really get things cleared I will start to check out again what can be applies as patch.. PS: who controls Kannel releases now? -- &Kalle || http://iki.fi/rpr/
RE: [RFC] mysql interface to kannel?
I do see your point. Kannel has is quite monolithic and there is a lot of features that would be nice 2 have, which in turn could result in a feature blown kannel. But youre basically talking about rewritting it from scratch. Java might be a portable language, but still, we have a lot c-code that works. Rewritting kannel from scratch is a major project. It will take quite a while. I like your idea though. I'm not sure whether Java is the way to go. I might be. But that pretty much prevents us from reusing the existing code. I like the layer idea. The separation of the layers you have suggested seems very sensible. Perhaps it should be possible to dynamic loadable modules (like in apache). This would allow people to implement various features, that might not be smart to have in the kannel core. If this functionality was archieved using corba or similar, then people could write modules in the language that they fancy. Still, I think delivery reports is a pretty important feature that should be implemented in the existing version of kannel, and I still intend to do this. Christian. -Original Message- From: Roy Smith Sent: ma 23-07-2001 00:18 To: Cc: [EMAIL PROTECTED] Subject:RE: [RFC] mysql interface to kannel? Before hooking a database into Kannel, I suggest the group first decides exactly what it wants Kannel to be. I got flamed a while back by somebody who claimed that Kannel was and should always be a simple transport mechanism. Yet Christian wants to implement a database and delivery reports. (The two go hand in hand since to support delivery reports requires a stateful view of the message lifecycle.) My observation of Kannel was that it was not well documented, and therefore relied heavily on its founders for forward momentum. As a former user of Kannel, I concluded the following :- + it is difficult to add new components + as a monolithic process, faults could not be contained, but rather brought the whole service down + it is not possible to distribute for increased reliability & performance + the need to innovate at the smsc level caused incompatibilities and kludges + I had big problems porting to a 64-bit Solaris system. The code is not very portable in places + the number of segmentation faults reported on this list leads me to believe that it has not been stressed + the inability to deal with interleaved incoming and outgoing messages confimrs this My 2c, is that Kannel should be redesigned into a number of layers :- [external interfaces, smtp, http, etc] [message formatters, dealing with TTML, OTA, MMS, ringtones, icons, etc] [transport manager, dealing with QoS, multiple smsc connections, cost/destination/performance based routing] [smsc connectors, much along the lines of the existing smsc modules, but running as discrete processes or Java threads] It should be 99% Java (although there may be reasons why the serial port handling is better done in C). It may also be desirable to leverage the gnokii work, although I confess I don't know gnokii in detail. Each layer should expose either an XML and Java object interface (or both), so it should be possible to use just the lower layers, if a custom application is required, or equally, it would be possible to easily write additional smsc modules conforming to the same API. We should aim to make this son-of-Kannel, the reference implementation of emerging messaging standards. We should also encourage smsc vendors, (Nokia, Sema, Logica, etc) to contribute the smsc modules. It should be covered by either a Gnu licence, or better, the Java Community Process. Note the absence of WAP. If anybody actually cares about WAP, the WAP components should be taken out and recast as a discrete product. The original premise that WAP and SMS sit within a common stack is not likely to happen in the real world, and I sense that the two differing applications of Kannel are tripping over each other. best regards Roy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Stipe Tolj Sent: 21 July 2001 12:16 Cc: [EMAIL PROTECTED] Subject: Re: [RFC] mysql interface to kannel? Importance: Low > > especialy for automatic billing support. > > - configuration facility: multi-groups like sms-user, sms-service, > > ota-config may be stored in mysql db, so there may be added or > > manipulated while runtime and the service would not have to be > > restarted to get notice of an update. This would make thinks > > particular slower, but may add incredible functionality gains. > > > > I think the DB interface would be quite useful but I would echo comments > from a previous post to ensure that there is a gw_ style wrapper approach > so that use is optional. Of cource. We want to make the usage of a DB system optional and Kannel should n
Re: [RFC] mysql interface to kannel?
Howdy, > + it is not possible to distribute for increased reliability & performance I don't think this is true, quite the contrary in fact. That's what the bearerbox does; distribution! > + I had big problems porting to a 64-bit Solaris system. The code is not > very portable in places We didn't have any problems, and as far as I'm aware Derry Hamilton (who did the original Solaris port) didn't have too many problems either. There were a few issues centred on threads and signal handling, but a week or so of work took care of those without too much drama. > + the number of segmentation faults reported on this list leads me to > believe that it has not been stressed The CVS version certainly hasn't been too much, but the development releases are fairly reliable. > + the inability to deal with interleaved incoming and outgoing messages > confimrs this That's only one SMSC. The problems in that module have nothing to do with Kannel archictecture, and everything to do with the nastiness of the GSM AT command set implementation. So I disagree with that comment entirely. > My 2c, is that Kannel should be redesigned into a number of layers :- > > [external interfaces, smtp, http, etc] > [message formatters, dealing with TTML, OTA, MMS, ringtones, icons, etc] > [transport manager, dealing with QoS, multiple smsc connections, > cost/destination/performance based routing] > [smsc connectors, much along the lines of the existing smsc modules, but > running as discrete processes or Java threads] These are good suggestions, though why "discrete processes"? And why Java? > It should be 99% Java (although there may be reasons why the serial port > handling is better done in C). Ummm. Why? Throwing a new language at the problem is unlikely to solve anything directly. Yes, there are certain interfaces which would benefit from built-in class handling functionality from a language, but these are just as likely to benefit from C++ or Smalltalk than from Java. I think you are betraying your biases here rather than providing a reasonable argument as to *why* we would benefit from using Java in particular. And, as you point out, some of the low-level bit-fiddling that we do (and there's a lot of it) along with the WAP stack material, and the serial interface handling stuff is going to be more difficult in Java than in C. There are countless other issues with a change of language at this stage, though I'm certainly not absolutely sold on C as such. If you can provide a reasonable defence of why Java as such is going to rock our respective worlds, then I'm all ears. > It may also be desirable to leverage the > gnokii work, although I confess I don't know gnokii in detail. Gnokii is GPL. Kannel is BSD. Using gnokii is entirely undesirable. > Each layer should expose either an XML and Java object interface (or both), > so it should be possible to use just the lower layers, if a custom > application is required, or equally, it would be possible to easily write > additional smsc modules conforming to the same API. These are good architectural suggestions, obviously my previous Java comments still holding. > We should aim to make this son-of-Kannel, the reference implementation of > emerging messaging standards. We should also encourage smsc vendors, (Nokia, > Sema, Logica, etc) to contribute the smsc modules. It should be covered by > either a Gnu licence, or better, the Java Community Process. Well, vendors are more than welcome to contribute as it stands. Though, strangely, they don't appear to be particularly interested, most likely because of the ridiculous sums of money they charge for their own proprietary solutions. The Kannel community has expressed little interest in a change of license, and consequently if you want to change the license, you'll have to go it without their support. > Note the absence of WAP. If anybody actually cares about WAP, the WAP > components should be taken out and recast as a discrete product. The > original premise that WAP and SMS sit within a common stack is not likely to > happen in the real world, and I sense that the two differing applications of > Kannel are tripping over each other. This is a valid criticism. Splitting the WAP and SMS components completely has definite advantages. Basically, at this stage, we have the following material; 1) Software load-balancer (bearerbox) 2) WAP Gateway (wapbox) 3) SMS Gateway (smsbox) and there may be certain advantages to this approach (and splitting it up accordingly into those sub-projects). See ya, Nick -- Nick Clarey, System Architect| "Sometimes when you fill a vacuum, 3G LAB | it still sucks." - Rob Pike ph 44-1223-478900 fax 44-1223-478901 |
Re: [RFC] mysql interface to kannel?
>Hi, > >I haven't watched the thread carefully, so I hope, my comment >will not be offtopic :-) > >There are several problems with notifications (delivery reports). >Different protocols use different ways of identifying sm's. >For example UCP/EMI identifies sm's based on combination >of timestamp (precision in seconds) and recepient's phone number. >Omnitel's proprietary protocol MAM gives you unique integer. >Sema OIS gives you SMSC reference number, which you can combine >with phone number and accept time. And if I understand PDU correctly, >than you can receive SMSC timestamp and recepient address too. >So first of all, you have to create generic layer to encapsulate >these differences between various protocols. > >The second problem is, how to match sms and notification. >I see the only possible solution and this is based on database. >Yes, you may store this data in memory and make fast lookups >through some hash table, but such scheme doesn't offer persistance >and it isn't scalable (my previous employer was sending >cca 1/4 million sms per month). > > Leo > In my point of view, going for a database abstraction layer in Kannel is the right choice. Your points are valid but it shouldnt be a problem to match a SMSC based unique ID to a kannel internal unique ID by mapping it with the SMSC ID of kannel. I'm currently running a front end to kannel doing logging / authentication / accounting of SMS flowing through kannel and I'm running far more than 1/4 million SMS per month and my small Linux box has absolutely no problem coping with the speed and use. The design should be in my eyes: a) incoming SMS requesting delivery report gets a unique ID at delivery to the SMSC. This unique ID is returned in the result. b) delivery report is received from the SMSC: the original requests gets looked up in the local database. If not found, discard it. If found, lets call the URL specified in the delivery report with the unique ID. This could be user specific. Example group = sendsms-user username = my-username password = my-password reports = "http://www.xyz.com/delivery-reports?id=%d"; override-reports = true or while requesting the URL have something like this http://localhost:1300/cgi-bin/sendsms?from=123&to=123&user=xxx&pass=xxx&text=the+message+to+send&delivery-report=http://mysite.com/cgi-bin/delivery-report?someid The database then would include the following: - source of message (username) - unique ID in the view of Kannel - smsc it was sent to - unqiue ID in the view of the SMSC - Timestamp of message - Lifetime of message - URL to call on buffering - URL to call on delivery - URL to call on non delivery a taks then should delete all expired messages after the lifetime has expried and return a non delivery report. -- Andreas Fink Fink-Consulting -- Tel: +41-61-6932730 Fax: +41-61-6932729 Mobile: +41-79-2457333 Address: A. Fink, Schwarzwaldallee 16, 4058 Basel, Switzerland E-Mail: [EMAIL PROTECTED] Homepage: http://www.finkconsulting.com -- Something urgent? Try http://www.smsrelay.com/ Nickname afink
Re: [RFC] mysql interface to kannel?
Hi, I haven't watched the thread carefully, so I hope, my comment will not be offtopic :-) There are several problems with notifications (delivery reports). Different protocols use different ways of identifying sm's. For example UCP/EMI identifies sm's based on combination of timestamp (precision in seconds) and recepient's phone number. Omnitel's proprietary protocol MAM gives you unique integer. Sema OIS gives you SMSC reference number, which you can combine with phone number and accept time. And if I understand PDU correctly, than you can receive SMSC timestamp and recepient address too. So first of all, you have to create generic layer to encapsulate these differences between various protocols. The second problem is, how to match sms and notification. I see the only possible solution and this is based on database. Yes, you may store this data in memory and make fast lookups through some hash table, but such scheme doesn't offer persistance and it isn't scalable (my previous employer was sending cca 1/4 million sms per month). Leo Christian Have wrote: > > My 2c: > > Some form of sequence numbering might be the way to go. > Maybe the sequence number does not have to be generated > by kannel, but can be specified by the user (eg. through > a http parameter). Then only if a sequence number, is specified > kannel will create a delivery report. > > The idea of letting the user examine the state of a sms is > problematic. For this to be realized, kannel must "remember" > different message for a certain amount of time. I think it would > be easier if kannel (the smsbox) took some sort of action upon > recieving a delivery report from the bb (it could fetch an url, > write to a file, etc). Optimally, this would be configurable. > > Christian. > > -Original Message- > > From: Bruno David Simões Rodrigues > > Sent: sø 22-07-2001 21:48 > > To: Christian Have; [EMAIL PROTECTED] > > Cc: > > Subject:Re: [RFC] mysql interface to kannel? > > I had think about generating a serial number for all messages sent (and > > return it on smsbox http > > interface) and then the user can request the state of the message on > other > > process (php or something) > > that analize the bearerbox_access and see what happened with the > message. > > And the notify reply just gets dumped on the access log. > > I haven't had time to think more about that or about other solution, but > If > > everyone would like to have > > delivery reports, let's talk about the best way to do it. > > -- > > Bruno Rodrigues > > - Original Message - > > From: "Christian Have" <[EMAIL PROTECTED]> > > To: "Stipe Tolj" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> > > Sent: Friday, July 20, 2001 2:21 PM > > Subject: RE: [RFC] mysql interface to kannel? > > Besides that, I have a question to the list: > > Is anyone working with some sort of delivery reports for > > kannel? I'm going to work on delivery reports in the next couple > > of weeks or so, so if anyone can help me (or I can help anybody) let me > > know... > > I think i've seen the topic on the list before... > > Sincerely, > > Christian Theil Have. -- - Leos Literak Software Engineer mobile: +420-605-849-087 phone: +420-2-21-970-245 fax:+420-2-21-970-241 e-mail: [EMAIL PROTECTED]
RE: [RFC] mysql interface to kannel?
My 2c: Some form of sequence numbering might be the way to go. Maybe the sequence number does not have to be generated by kannel, but can be specified by the user (eg. through a http parameter). Then only if a sequence number, is specified kannel will create a delivery report. The idea of letting the user examine the state of a sms is problematic. For this to be realized, kannel must "remember" different message for a certain amount of time. I think it would be easier if kannel (the smsbox) took some sort of action upon recieving a delivery report from the bb (it could fetch an url, write to a file, etc). Optimally, this would be configurable. Christian. -Original Message- From: Bruno David Simões Rodrigues Sent: sø 22-07-2001 21:48 To: Christian Have; [EMAIL PROTECTED] Cc: Subject: Re: [RFC] mysql interface to kannel? I had think about generating a serial number for all messages sent (and return it on smsbox http interface) and then the user can request the state of the message on other process (php or something) that analize the bearerbox_access and see what happened with the message. And the notify reply just gets dumped on the access log. I haven't had time to think more about that or about other solution, but If everyone would like to have delivery reports, let's talk about the best way to do it. -- Bruno Rodrigues - Original Message - From: "Christian Have" <[EMAIL PROTECTED]> To: "Stipe Tolj" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, July 20, 2001 2:21 PM Subject: RE: [RFC] mysql interface to kannel? Besides that, I have a question to the list: Is anyone working with some sort of delivery reports for kannel? I'm going to work on delivery reports in the next couple of weeks or so, so if anyone can help me (or I can help anybody) let me know... I think i've seen the topic on the list before... Sincerely, Christian Theil Have.
RE: [RFC] mysql interface to kannel?
Before hooking a database into Kannel, I suggest the group first decides exactly what it wants Kannel to be. I got flamed a while back by somebody who claimed that Kannel was and should always be a simple transport mechanism. Yet Christian wants to implement a database and delivery reports. (The two go hand in hand since to support delivery reports requires a stateful view of the message lifecycle.) My observation of Kannel was that it was not well documented, and therefore relied heavily on its founders for forward momentum. As a former user of Kannel, I concluded the following :- + it is difficult to add new components + as a monolithic process, faults could not be contained, but rather brought the whole service down + it is not possible to distribute for increased reliability & performance + the need to innovate at the smsc level caused incompatibilities and kludges + I had big problems porting to a 64-bit Solaris system. The code is not very portable in places + the number of segmentation faults reported on this list leads me to believe that it has not been stressed + the inability to deal with interleaved incoming and outgoing messages confimrs this My 2c, is that Kannel should be redesigned into a number of layers :- [external interfaces, smtp, http, etc] [message formatters, dealing with TTML, OTA, MMS, ringtones, icons, etc] [transport manager, dealing with QoS, multiple smsc connections, cost/destination/performance based routing] [smsc connectors, much along the lines of the existing smsc modules, but running as discrete processes or Java threads] It should be 99% Java (although there may be reasons why the serial port handling is better done in C). It may also be desirable to leverage the gnokii work, although I confess I don't know gnokii in detail. Each layer should expose either an XML and Java object interface (or both), so it should be possible to use just the lower layers, if a custom application is required, or equally, it would be possible to easily write additional smsc modules conforming to the same API. We should aim to make this son-of-Kannel, the reference implementation of emerging messaging standards. We should also encourage smsc vendors, (Nokia, Sema, Logica, etc) to contribute the smsc modules. It should be covered by either a Gnu licence, or better, the Java Community Process. Note the absence of WAP. If anybody actually cares about WAP, the WAP components should be taken out and recast as a discrete product. The original premise that WAP and SMS sit within a common stack is not likely to happen in the real world, and I sense that the two differing applications of Kannel are tripping over each other. best regards Roy -Original Message- From: [EMAIL PROTECTED] [mailto:[EMAIL PROTECTED]]On Behalf Of Stipe Tolj Sent: 21 July 2001 12:16 Cc: [EMAIL PROTECTED] Subject: Re: [RFC] mysql interface to kannel? Importance: Low > > especialy for automatic billing support. > > - configuration facility: multi-groups like sms-user, sms-service, > > ota-config may be stored in mysql db, so there may be added or > > manipulated while runtime and the service would not have to be > > restarted to get notice of an update. This would make thinks > > particular slower, but may add incredible functionality gains. > > > > I think the DB interface would be quite useful but I would echo comments > from a previous post to ensure that there is a gw_ style wrapper approach > so that use is optional. Of cource. We want to make the usage of a DB system optional and Kannel should not depend on any other software parts. An abstraction layer may be a good idea for that, so that optional support may be abstracted and different DB types implemented. > Updating running configurations is much tricky and doesn't depend > on holding the configuration in a DB. There was some discussion > lead by Lars some time ago about doing this so the archives > might hold some interesting comments. Unfortunately, all Kannel > code assumes that config file is read once at start-up and would > require major surgery to move to a dynamic model. Basicly Kannel has hooks that look up the configuration directives while runtime. These would be used to query the DB systems for dynamic loading of the specific configuration directives. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 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: [RFC] mysql interface to kannel?
It should only generate the serial number or "sequence number" if you would ask for a delivery report/notify/whatever. -- Bruno Rodrigues - Original Message - From: "Steve Kennedy" <[EMAIL PROTECTED]> To: <[EMAIL PROTECTED]> Sent: Sunday, July 22, 2001 10:50 PM Subject: Re: [RFC] mysql interface to kannel? > How about two entry url's or something, one that just sends and > you dont care whether it's delivered or not, and another that > does the serialisation (which will obviously add overhead). > > Steve > > -- > NetTek Ltd tel +44-(0)20 7483 1169 fax +44-(0)20 7483 2455 > Flat 2,43 Howitt Road, Belsize Park,London NW3 4LU > mobile 07775 755503 Epage [EMAIL PROTECTED] [body only] > >
Re: [RFC] mysql interface to kannel?
On Sun, Jul 22, 2001 at 08:48:34PM +0100, Bruno David Simões Rodrigues wrote: > I had think about generating a serial number for all messages sent (and > return it on smsbox http > interface) and then the user can request the state of the message on other > process (php or something) > that analize the bearerbox_access and see what happened with the message. > And the notify reply just gets dumped on the access log. How about two entry url's or something, one that just sends and you dont care whether it's delivered or not, and another that does the serialisation (which will obviously add overhead). Steve -- NetTek Ltd tel +44-(0)20 7483 1169 fax +44-(0)20 7483 2455 Flat 2,43 Howitt Road, Belsize Park,London NW3 4LU mobile 07775 755503 Epage [EMAIL PROTECTED] [body only]
Re: [RFC] mysql interface to kannel?
I had think about generating a serial number for all messages sent (and return it on smsbox http interface) and then the user can request the state of the message on other process (php or something) that analize the bearerbox_access and see what happened with the message. And the notify reply just gets dumped on the access log. I haven't had time to think more about that or about other solution, but If everyone would like to have delivery reports, let's talk about the best way to do it. -- Bruno Rodrigues - Original Message - From: "Christian Have" <[EMAIL PROTECTED]> To: "Stipe Tolj" <[EMAIL PROTECTED]>; <[EMAIL PROTECTED]> Sent: Friday, July 20, 2001 2:21 PM Subject: RE: [RFC] mysql interface to kannel? Besides that, I have a question to the list: Is anyone working with some sort of delivery reports for kannel? I'm going to work on delivery reports in the next couple of weeks or so, so if anyone can help me (or I can help anybody) let me know... I think i've seen the topic on the list before... Sincerely, Christian Theil Have.
Re: [RFC] mysql interface to kannel?
> > especialy for automatic billing support. > > - configuration facility: multi-groups like sms-user, sms-service, > > ota-config may be stored in mysql db, so there may be added or > > manipulated while runtime and the service would not have to be > > restarted to get notice of an update. This would make thinks > > particular slower, but may add incredible functionality gains. > > > > I think the DB interface would be quite useful but I would echo comments > from a previous post to ensure that there is a gw_ style wrapper approach > so that use is optional. Of cource. We want to make the usage of a DB system optional and Kannel should not depend on any other software parts. An abstraction layer may be a good idea for that, so that optional support may be abstracted and different DB types implemented. > Updating running configurations is much tricky and doesn't depend > on holding the configuration in a DB. There was some discussion > lead by Lars some time ago about doing this so the archives > might hold some interesting comments. Unfortunately, all Kannel > code assumes that config file is read once at start-up and would > require major surgery to move to a dynamic model. Basicly Kannel has hooks that look up the configuration directives while runtime. These would be used to query the DB systems for dynamic loading of the specific configuration directives. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 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: [RFC] mysql interface to kannel?
> - logging facility: access.log data may be stored to mysql db, > especialy for automatic billing support. > - configuration facility: multi-groups like sms-user, sms-service, > ota-config may be stored in mysql db, so there may be added or > manipulated while runtime and the service would not have to be > restarted to get notice of an update. This would make thinks > particular slower, but may add incredible functionality gains. > I think the DB interface would be quite useful but I would echo comments from a previous post to ensure that there is a gw_ style wrapper approach so that use is optional. Updating running configurations is much tricky and doesn't depend on holding the configuration in a DB. There was some discussion lead by Lars some time ago about doing this so the archives might hold some interesting comments. Unfortunately, all Kannel code assumes that config file is read once at start-up and would require major surgery to move to a dynamic model.
AW: [RFC] mysql interface to kannel?
We should make sure that Kannel does not catch the GPL virus. Those with commercial interests in Kannel would be hard pressed to extract the free pieces from the GPL code. Regards Joerg > -Ursprüngliche Nachricht- > Von: Christian Have [mailto:[EMAIL PROTECTED]] > Gesendet am: Freitag, 20. Juli 2001 15:21 > An: Stipe Tolj; [EMAIL PROTECTED] > Betreff: RE: [RFC] mysql interface to kannel? > > Methinks it's a very good idea with an database. MySQL is also a > good choice (GPL, fast db, I love MySQL), but we shouldn't > make kannel dependent of MySQL. If we choose to implement > logging and such to the database, I think we should first define an > abstraction layer. The abstraction layer should ease the integration > with other databases as well. Besides that, I'd love to > help, especially > with MySQL... > > Besides that, I have a question to the list: > Is anyone working with some sort of delivery reports for > kannel? I'm going to work on delivery reports in the next couple > of weeks or so, so if anyone can help me (or I can help > anybody) let me > know... > I think i've seen the topic on the list before... > > Sincerely, > Christian Theil Have. > > > Original Message- > > From:Stipe Tolj > > Sent: fr 20-07-2001 13:35 > > To: [EMAIL PROTECTED] > > Cc: > > Subject: [RFC] mysql interface to kannel? > > > Is there any interest that we may start implementing a DB based > > interface to Kannel for various functions. This was on my TODO list > > for quite a time and I would like to kick-off development on that. > > > > We have incorporated MySQL client functions to Kannel within our > > MSISDN Provisioning concept, but there are way more use for > storing or > > retrieving data to a database from Kannel: > > > > - logging facility: access.log data may be stored to mysql db, > > especialy for automatic billing support. > > - configuration facility: multi-groups like sms-user, sms-service, > > ota-config may be stored in mysql db, so there may be added or > > manipulated while runtime and the service would not have to be > > restarted to get notice of an update. This would make thinks > > particular slower, but may add incredible functionality gains. > > > > I think of a SMS gateway hosting service, where customers get an HTTP > > based Account and log into a HTTP server (using PHP and MySQL) and > > configure the way Kannel sends their SMS messages via EMI or other > > SMSC protocols (more or less) individual, including incoming SMS > > Services. Of course you have to keep certain options under > restriction > > so that you have control of the system and billing. > > > > If there is interest in incorporating (at least in the first step) > > MySQL interface for Kannel I may get my hands on the above issues. > > > > Stipe > > > > [EMAIL PROTECTED] > > --- > > Wapme Systems AG > > > > Münsterstr. 248 > > 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: [RFC] mysql interface to kannel?
Methinks it's a very good idea with an database. MySQL is also a good choice (GPL, fast db, I love MySQL), but we shouldn't make kannel dependent of MySQL. If we choose to implement logging and such to the database, I think we should first define an abstraction layer. The abstraction layer should ease the integration with other databases as well. Besides that, I'd love to help, especially with MySQL... Besides that, I have a question to the list: Is anyone working with some sort of delivery reports for kannel? I'm going to work on delivery reports in the next couple of weeks or so, so if anyone can help me (or I can help anybody) let me know... I think i've seen the topic on the list before... Sincerely, Christian Theil Have. Original Message- From: Stipe Tolj Sent: fr 20-07-2001 13:35 To: [EMAIL PROTECTED] Cc: Subject: [RFC] mysql interface to kannel? Is there any interest that we may start implementing a DB based interface to Kannel for various functions. This was on my TODO list for quite a time and I would like to kick-off development on that. We have incorporated MySQL client functions to Kannel within our MSISDN Provisioning concept, but there are way more use for storing or retrieving data to a database from Kannel: - logging facility: access.log data may be stored to mysql db, especialy for automatic billing support. - configuration facility: multi-groups like sms-user, sms-service, ota-config may be stored in mysql db, so there may be added or manipulated while runtime and the service would not have to be restarted to get notice of an update. This would make thinks particular slower, but may add incredible functionality gains. I think of a SMS gateway hosting service, where customers get an HTTP based Account and log into a HTTP server (using PHP and MySQL) and configure the way Kannel sends their SMS messages via EMI or other SMSC protocols (more or less) individual, including incoming SMS Services. Of course you have to keep certain options under restriction so that you have control of the system and billing. If there is interest in incorporating (at least in the first step) MySQL interface for Kannel I may get my hands on the above issues. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 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
[RFC] mysql interface to kannel?
Is there any interest that we may start implementing a DB based interface to Kannel for various functions. This was on my TODO list for quite a time and I would like to kick-off development on that. We have incorporated MySQL client functions to Kannel within our MSISDN Provisioning concept, but there are way more use for storing or retrieving data to a database from Kannel: - logging facility: access.log data may be stored to mysql db, especialy for automatic billing support. - configuration facility: multi-groups like sms-user, sms-service, ota-config may be stored in mysql db, so there may be added or manipulated while runtime and the service would not have to be restarted to get notice of an update. This would make thinks particular slower, but may add incredible functionality gains. I think of a SMS gateway hosting service, where customers get an HTTP based Account and log into a HTTP server (using PHP and MySQL) and configure the way Kannel sends their SMS messages via EMI or other SMSC protocols (more or less) individual, including incoming SMS Services. Of course you have to keep certain options under restriction so that you have control of the system and billing. If there is interest in incorporating (at least in the first step) MySQL interface for Kannel I may get my hands on the above issues. Stipe [EMAIL PROTECTED] --- Wapme Systems AG Münsterstr. 248 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
