Re: DATAGRAM MODE

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/
-------------------------------------------------------------------