**>From: "fred" <[EMAIL PROTECTED]> **>To: "devel" <[email protected]> **>Subject: Re: messageid DLR parameter **>Date: Fri, 11 Feb 2005 18:44:37 +1100 **> **>"Well, to get to the 15 Bytes transferred, I did not include the thousands **>of CPU cycles to create and pass those 15 bytes from bearerbox to smsbox. **>For someone with a GHz processor and lots of RAM, they don't care about the **>extras resources used. But, for us that have to support legacy systems **>running at 400Mhz with 128MB,....blah blah blah" **> **>Is this for REAL ???
Actually, it is. I recently helped a company migrate to Kannel running on my embedded environment. They were originally using a DEC Alpha with Ultrix running the old Ztango SMS service content/provisioning system. I'm sure Kalle will remember his fellow Finnish rival, Ztango ;-). BTW, Kalle, what ever happen to Julie, Pasi, and Richard(s)? **>I have this picture of you guys, its like the 1960s or so huddled over those **>24x80 green screens too.... Picture my ICE connected to my analyzer through a JTAG cable setting breakpoints on ROM code to see if gwthread_sleep() is flaking out because I'm not allowing enough CPU cycles to service the clock interrupt. And, my ssh sessions into my unix boxes are 80x24, green on black :-). **>thats why the code is so sqished up so you can fit as much on those poor **>24x80 screeen....and minimal docos, **>no doxygen, no color syntax hi-lighting, you know it is 2005 now........ **>and none of the code looks like it would remotely pass a code review in a **>corporate environment like a bank,etc... **>it mostly looks very hackerish...... Chances are that you are seeing the results of source code being released circa 1999. WapIT was not making money off the Kannel code but the Valued Added Services developed on top of Kannel. I had always hoped (back in 1999-2001) that they would be around long enough to help fill in the comments missing in the code (octstr.c and urltrans.c would be much easier to grasp for newcomers with some more details about the inputs/outputs/limits of each function). But, I guess the funding ran out before in-the-source documentation could be added. Probably, in one of the Probate's drawers is a detailed architectural and system design with complete interface/class/structure diagrams. Someone recently said they were planning to submit some design documents about Kannel. Also, I was planning on taking a crack at commenting the gwlib and the toplevel of gw after my updates to the userguide. I'll start on it as soon as I'm done with the two current projects I have on Kannel wishlist (my statusbox [for retrieval of SMS status when presented with the UUID sms.id] and TLVbox [for exposing TLA/TLV from SMPP Optional Parameters]). **>so theres my rant...i'm sure you'll try an shoot me now!! Not shoot you...just try to encourage you to see that Kannel's not just for PC-based SMSC gatewaying anymore. I might represent the extreme case of Kannel porting. I haven't seen anyone on the net talking about Kannel on an ARM7 processor (although we kind of talked about the possibility of Kannel on the Dragonball [a la Palm] or StrongARM [a la iPaq] in Hong Kong back in 2000). But, I'm sure crazy people like me are out there. Don't think that limited resources are ONLY due to old equipment. Cost and space is another issue. You'ld be surprised at some places Kannel code has been embedded into. Ever wonder how some of those long-haul trucking companies keep track of their trucks? See ya... d.c.
