Don't break the interface

Ian and Jonathon have been paired up on resolving a long standing omission from our system, aggregating inbound long messages.

Currently when a subscriber sends a long message to one of our SMS long numbers or short codes, each part of that message arrives in the inbox, or is pushed to our customers web service, individually. Aggregating the messages for multiple accounts while maintaining performance was a reasonably significant architectural problem to resolve.

We had looked at it before but were never quite happy with the solution. I finally committed the development time to do it as a result of the a case being raised by a very patient and reasonable customer. This time we were ready.

One of the constraints on any changes we make to our systems is preserving the interface to customers who use our API. In our initial plans we were going to potentially break it for some people.

Ian describes it in more detail in his post: Esendex Inbound Multipart Messaging Update. While we weren't strictly breaking the interface, if our customers had made reasonable assumptions about the length strings being passed it could break their application.

Not happy with this, the three of us sat down and we did come up with a solution that satisfied the internal architecture of our system while still supporting our existing customers.

We are going to provide an API option on an account to aggregate long messages. While we'll be storing messages in their aggregated form in our system. For those accounts with that option switched off, the API will re-split the messages before delivering them.

All existing accounts will have the option turned off by default and all new accounts will have the option turned on.

It makes the Options page a little more complicated but it keeps everyone working, which is what it's all about.