I have been making use of binfo with further embeded key:values in the string for this kind of problem of passing smsc specific key/values to the smpp driver. it may not be the right thing to do, but at least I didn't need to change everywhere for another parameter since its already there and not much using of it at the moment........
Cheers ----- Original Message ----- From: "Stipe Tolj" <[EMAIL PROTECTED]> To: "Enver ALTIN" <[EMAIL PROTECTED]> Cc: <[email protected]> Sent: Wednesday, September 28, 2005 1:27 AM Subject: Re: DATAGRAM MODE -#- MailID:PAAA > Enver ALTIN wrote: > > > Hey, > > > > On Mon, 2005-08-29 at 12:05 +0200, Alejandro Guerrieri wrote: > > > >>Count me in! (Now it's 2 Alejandro's ;) ) I've had to change the darn > >>ESM_CLASS to DEFAULT about a thousand times :) > > > > > > I think general consensus is to prevent adding SMSC-specific parameters > > to the sendsms interface, so I think this patch is a bit controversial > > and needs to be properly designed before it gets committed. > > yep, agreed. The patch is definetly _too_ SMPP centric in this case. At least > the way the sendsms interface is changed. > > > Maybe we can introduce a generic-purpose field and use it for passing > > SMSC-specific parameters to the SMSCConn via sendsms? Maybe we can just > > let it in, and change the behavior later? I'm not really sure which way > > is better. > > agree'ing again. This discussion is a flaming issue on the list. We need a > construct to abtractly "de-abstract" the sendsms interface parameters ;) > > What does that mean? ;) ... now, actually the smsbox should hide "as much as > possible" the SMSC specific issues to the HTTP client/caller. In this case I > don't know how we can do that exactly. > > But I _do_ agree that we need some kind of "meta" field that is passed > "unchanged/uninterpreted" from smsbox layer to bearerbox and hence to the > specific smsc implementation to let the smsc module itself decide how it should > use the information presented in the meta field. > > How can this actually look like? > > maybe something like > > http://..../sendsms?...&meta=XXX&;... > > where the XXX value of the meta parameter is again urlencoded in order to be > parsed later on with a seperate key=value chain list. > > More ideas on this? > > Stipe > > mailto:stolj_{at}_wapme-group.de > ------------------------------------------------------------------- > Wapme Systems AG > > Vogelsanger Weg 80 > 40470 Düsseldorf, NRW, Germany > > phone: +49.211.74845.0 > fax: +49.211.74845.299 > > mailto:info_{at}_wapme-systems.de > http://www.wapme-systems.de/ > ------------------------------------------------------------------- >
