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 **
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 **
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?
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?
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?
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?
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?
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]
[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?
- 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.
