Jon Houser wrote:
If it's a spec breaker, make it something you have to turn on.
Then you can support the broken SMSCs should you need to, but the
end-user has to enable it. Heck, even call it "hack-send-in-order" or
something so you know every time you see it that it's just a hack.
Granted there's the issue of not breaking this functionality as time
progresses, but looking at the patch he submitted, it didn't look like
that big of a deal.
Again I'm not advocating for the addition of this feature.
Personally I don't need it and don't care. But if this is some big guy
SMSC and if their SMSC indeed *needs* to work this way for some reason,
it should definitely be considered.
My 2 cents (or whatever you local currency may be that is of
equivalence). :P
ok, good 2 cents in my opinion ;)
Actually Enver states that this is a "home-brew" SMSC, acting as proxy only for
billing purposes.
Now, taking into account your suggestion that we may make it "optional" takes my
voting from -0 to +0. Which is at least some improvement.
Now, as far as I understand, you're voting +0 too on taking this approach into
account regarding ordering. Alex votes -1, clearly.
Now, I'd like to hear more opinions on this.
@Enver: can we "speed" up that priority ordering here? in order not to use
octstr_compare() that consumes time? Can you have a benchmark test that conducts
what the performance "loose" would be in adding this optional feature?
I'd like to estimate what the general impact on performance would be.... ok, and
I'm too lazy to setup a test-suite for this on my own ;) I admit. But this is
due to preperations to get more open bug reports resolved and get closer to next
stable release.
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/
-------------------------------------------------------------------
