Stipe, et al,
>> sorry but it seems we make workarounds for buggy SMSC. I'm -1 for this
>> patch. They must fix SMSC instead of adding some workarounds where
>> those don't belong to. Priority has _nothing_ todo with receiver and
>> udh. Instead SMSC devels should read spec properly (EMI 4.0, GSM
>> 03.38, GSM 03.40). There is not sign of catenated msgs ordering.
As a member of a company that develops their own SMSC, I have to
say that lots of people break specs, even the big guys and handset
manufacturers. As such, to be fully compliant with the market and not
just the specs, you sometimes have to allow for stupid hacks. Otherwise
you can feel good inside for being 100% compliant, sure, but you won't
be able to support the market (which doesn't really make sense).
Now that being said, if in fact this is some small guy (AKA home
brew) SMSC, I can agree completely with not adding the functionality.
They should in fact fix their code unless they have a *really* good
reason for it to work like this. They don't represent a lot in the way
of installed systems in that case, so it shouldn't be that big of a deal
for them to fix their code.
Back to being an SMSC developer, I can say that there are possible
good reasons for wanting the above functionality. The UDH spec allows
for an ID that should differentiate each message from another so you
know what pieces get put back together. However a lot of vendors are
lazy and only ever set this to some default value, ie. 1. Even if they
don't, there's never any real guarantee that the unique ID is actually
unique for that connection. (I refer to the concat/SAR reference number
in the above.) Now if you want some higher level functionality like
displaying multi-part messages as a single message for end-user tools,
retries where you resend all parts should a single part fail, etc., you
kind of need to know which pieces go together. I'm sure there are other
uses, but those are the ones we've explored that I can think of.
> We really don't want to add workarrounds for bugs of other people's
> software, that's why specs are for.
>
> Sounds drastic, but it has to be programatic, otherwise we're the one to
> blame, since we do everything, but not the clean words of the spec.
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
Jon
