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