Hi Charith, This is a very good idea indeed. As many pointed out, there are immense benefits in doing this and it is indeed great for a GSoC.
I think Sagara has a good point. Since there is a character limit per message you need to think about how larger payloads can be transfered. For cell phones I remember there was a format where you can send one single message consisting of up to some max number of separate messages. I remember this to be Nokia specific thing since they appeared messed up in the old Ericcsson I used to have.[ Am writing this mail offline so can't google :( Not sure whether it was adopted as a standard ] . You can definitely take a look at such things. Ultimately if you can comeup with a protocol binding (such as the WSDL bindings for HTTP or SMTP) that would be an ideal outcome. Such a binding would at least become a de-facto standard if you are successful :) Guys that have more knowledge in SMS can help out here, Can SMS transfer binary ? [I doubt whether it can. It seemed to be only ASCII]. If so you can think of more space efficient XML serializations such as fastinfoset. Just some ideas Ajith 2009/3/19 Sagara Gunathunga <sagara.gunathu...@gmail.com>: > Hi Charith, > It always better to implement for a specification instead of a > specific implementation such as SMSlib , Initially you can set up > SMPPSim for testing it just like running a HTTP server. > > Any way what is your plan to handle size of the the payload messages ..? > > This is not a problem with other protocols like HTTP,JMS or mail but > SMS you need to think about the size of the massage. According to > the SMPP spec "short_message size" is limited to 254 Octet String, > also this value may be vary with networks. pay your attention for > possible solution for this. > > Thanks , > -- Ajith Ranabahu Reading, after a certain age, diverts the mind too much from its creative pursuits. Any man who reads too much and uses his own brain too little falls into lazy habits of thinking - Albert Einstein
