Attention is currently required from: keith.
1 comment:
Patchset:
I'm not sure I'm fully following you tbh, because from your previous (full) comment afaict you seem to state both that you are reordering and also that you are not reordering them?
I'm not "reordering" the SMS ...
WE just got an SMS for Alice. we dropped it in the database, the id is 5467, send SMS number 5467, now also look for other SMS for Alice and send them too.
^ This looks like on-purpose reordering to me (better called disordering?).
Also, as mentioned I'm not currently aware of the existing codeset regarding SMS, just wanted to raise the topic, share my concern regarding possible reordering happening on purpose due to the new algorithm.
We just got an SMS for Alice, we dropped it in the database, we don't care about the id, but we will now look in the database for all SMS for Alice and send them?
Sounds like the latter will keep you more happy
Yes that'd be the behavior I'd expect.
I guess when select()ing SMS for Alice they'll probably come sorted by sms id since it's probably an increasing key, so we get them ordered in inserted order by free (or we could order them explicitly in the SQL query).
> Is it not the MOST RECENT information that should have priority? Yes, on reflection, I think so.
I disagree here. Following this approach eg. in UDP, RTP, etc. you'd end up with tons of reordered packets. The fact that reordering may happen doesn't mean we should not be trying to send stuff in order imho.
As an aside, SMS is simply NOT time sensitive. not even on commercial networks. There is ZERO guarantee of chronological delivery
ACK, but as mentioned above the fact that there's no guarantee doesn't mean we should be trying our best to do so when we know how to do it.
To view, visit change 28342. To unsubscribe, or for help writing mail filters, visit settings.