can I send delivery request by this pattern? On 8/3/07, Alejandro Guerrieri <[EMAIL PROTECTED]> wrote: > > Don't worry, I won't write code until I get a hand on yours! :) > > Eagerly waiting to get your patch ;) > > Have a nice weekend. > > Alejandro. > > On 8/3/07, Alexander Malysh <[EMAIL PROTECTED]> wrote: > > Alejandro Guerrieri wrote: > > > > > _That's_ the whole point, yes! > > > > > > A few additional questions: > > > > > > * Your patch allows to send and receive meta data, or only send? > > > > it works both ways... > > > > > * How this interact with sqlbox? I can make the changes myself if > > > neccesary, but I don't want to duplicate work. > > > > sqlbox is not a part of official kannel, so you have to write patch > yourself > > and post it to devel@ :) But please wait until I post the patch... > > > > > > > > Regards, > > > > > > Alejandro > > > > > > On 8/3/07, Alexander Malysh <[EMAIL PROTECTED]> wrote: > > >> On Freitag, 3. August 2007, Alejandro Guerrieri wrote: > > >> > Wow, great news! > > >> > > > >> > This will ever make it into the main tree, or it will be kept as a > > >> > separate patch? > > >> > > >> I hope it will make it into main tree. With this patch nobody will > have > > >> to modify kannel sources for SMPP TLVs and we will have e.g. Mblox > > >> support out of the box :) > > >> > > >> > > > >> > I think it's a great addition for everyone using SMPP, since many > > >> > operators/aggregators are using optional parameters as a mean of > > >> > adding functionality to their SMPP implementations. Having this as > a > > >> > functional part in Kannel can make it a better option for many > people > > >> > IMHO (having to modify the source code to connect to an > > >> > operator/aggregator may not be feasible for some users). > > >> > > > >> > Great job, thanks! I can't wait to see it in action. > > >> > > > >> > Regards, > > >> > > > >> > Alejandro > > >> > > > >> > On 8/3/07, Alexander Malysh <[EMAIL PROTECTED]> wrote: > > >> > > Hi, > > >> > > > > >> > > I already done it. Patch is in my tree should just rebase it > against > > >> > > kannel.org. > > >> > > > > >> > > In my patch we have... > > >> > > > > >> > > In the config > > >> > > group = smpp-tlv > > >> > > name = some-name > > >> > > tag = 0x1601 > > >> > > type = integer|nulterminated|octetstring > > >> > > length = 4 > > >> > > > > >> > > Then in the msg struct I added meta_data field that can contain > any > > >> > > parameters not only for smpp. meta_data is formated as follows: > > >> > > meta_data = > ?group?key=value&key1=value1?smpp?some-name=ABC > > >> > > then SMPP module just set all TLVs that can be found in the smpp > > >> > > group of meta_data. > > >> > > > > >> > > With this approach it's possible to use this generic interface to > put > > >> > > some extra functionality into any SMSC module. > > >> > > > > >> > > I will rebase my patch and post it (hope todo it this weekend), > just > > >> > > be a bit patient. > > >> > > > > >> > > Alejandro Guerrieri wrote: > > >> > > > Dear List, > > >> > > > > > >> > > > A fellow member of this list and me are planning to implement a > > >> > > > generic way to send/receive TLV's (SMPP Optional Parameters) to > > >> > > > Kannel. The objective of our approach will be to develop a high > > >> > > > level abstraction of the TLV structure in order to allow Kannel > to > > >> > > > send and recognize specific TLV's just by writing special > > >> > > > configuration directives on it's conf files. > > >> > > > > > >> > > > The idea has matured to the point of writing fictitious (as of > now) > > >> > > > configuration directives and communication parameters. > > >> > > > > > >> > > > As we see it, the configuration for optional parameters should > go > > >> > > > into the core group. An "allow" directive could be put in place > to > > >> > > > limit the functionality of specific parameters to specific smpp > > >> > > > connections. > > >> > > > > > >> > > > For example: > > >> > > > > > >> > > > group = smpp-optional > > >> > > > group-id = msg_ticket > > >> > > > allowed-smsc-id = "smsc1;smsc2" > > >> > > > tlv-tag = 0x1404 > > >> > > > tlv-length = 15 > > >> > > > tlv-type = string > > >> > > > > > >> > > > group = smpp-optional > > >> > > > group-id = msg_custom_param > > >> > > > allowed-smsc-id = "smsc1;smsc2" > > >> > > > tlv-tag = 0x14FF > > >> > > > tlv-length = 2 > > >> > > > tlv-type = integer > > >> > > > > > >> > > > This would define two TLV's, one called "msg_ticket" at address > > >> > > > 0x1404 carrying a OctStr of 15 bytes in lenght. The second > would be > > >> > > > called "msg_custom_param" at address 0x14FF carrying an integer > of > > >> > > > 2 bytes. Both parameters only exists on the context of smpp > > >> > > > connections named "smsc1" and "smsc2". > > >> > > > > > >> > > > To avoid clashing with other modules, the parameters would be > > >> > > > "serialized" into a single parameter to be sent/received by the > > >> > > > HTTP/XML and even SQLBOX interface (with minor modifications). > The > > >> > > > syntax would be as follows: > > >> > > > > > >> > > > To send: > > >> > > > > >> > > > > > http://myhost:port/cgi-bin/sendsms?....&smpp_optional=msg_ticket=xxxxxxxx > > >> > >&msg_custom_param=123 > > >> > > > > >> > > > Note: the tag-value combination would have to be urlencoded of > > >> > > > course. > > >> > > > > > >> > > > To receive: > > >> > > > > > >> > > > We could use any free letter (maybe "v" ?) to receive the > tag-value > > >> > > > pairs, also urlencoded. > > >> > > > > > >> > > > So if we configure post-url with "http://myhost/myapp?params=%v > > >> > > > > > >> > > > We would receive a post with "params" (or any name we've > chosen) > > >> > > > loaded with: > > >> > > > > > >> > > > "msg_ticket=xxxxxxx&msg_custom_param=321" (It would also be > > >> > > > urlencoded). > > >> > > > > > >> > > > Any opinions or suggestions from the core Kannel mantainers and > > >> > > > fellow community members are welcome. > > >> > > > > > >> > > > Thank you in advance, > > >> > > > > >> > > -- > > >> > > Thanks, > > >> > > Alex > > >> > > >> > > >> -- > > >> Thanks, > > >> Alex > > >> > > > > > > > > > > -- > > Thanks, > > Alex > > > > > > > > > -- > Alejandro Guerrieri > Magicom > http://www.magicom-bcn.net/ > LinkedIn: http://www.linkedin.com/in/aguerrieri > >
-- --Vahid Ghafarpour. http://vahid.ghafarpour.ir/ vahid at ghafarpour dot ir ghafarpour at gmail dot com
