This is the roadmap for the 1.1 release of the SMS Framework. Please add your items and tickets to the issue tracker.
We will begin working on these tickets as soon as the 1.0 release is made.
- Improve international support (#197343)
- Standardized phone number format
- Drupal 6 release (#252568)
- Write more API documentation
- Improve the SMS Blast module (#276320)
- Ability to make double opt in optional (#279926 )
- More gateway modules that support receiving
- Improve sms_receive module
- Remove behavior mapping
Improve international support
Support for international messaging has always been a challenge because of a lack of resources on the subject. We'll need to focus on collecting information from users in different parts of the world in order to get an idea of what is needed to standardize support.
Standardized phone number format
There is currently no standard format in which to store and provide phone numbers. This is mainly due to a lack of resources and documentation about international numbering systems. The 1.1 release should include a standard way to store phone numbers. This is especially important for receiving and authenticating with SMS because the sender's mobile number as provided by caller ID must match the number stored in the database.
Improve sms_receive module
The receiving mechanisms in the framework should follow the same logical design as the sending mechnisms. This means letting individual gateway modules be the first point of contact when receiving a message from an external service. Currently, the sms_receive module was built for a very specific purpose: posting the contents of a text message to a node. It allows you to define callback URL, but not all gateways will use this method for incoming messages.The gateway modules should handle this and the sms_receive module should handle the process of parseing incomming messages and executing local Drupal events. Additionally, this module could be moved within the main sms.module as this might be considered core functionality for SMS.
A command builder. that would let administors define patterns to expect and execute different actions based on those commands. For example, the administrator could define the following pattern to RSVP a user to an event and indicate the number of guests they are bringing:
rsvp [event_nid] [field_guests]
If a user sent a message with the text:
+2315557575 rsvp 23 3
they would RSVP to the event with the node ID of 23 and add three guests.
Remove behavior mapping
Behavior mapping was created to allow different gateways to be used for different actions. This feature is not very useful and makes everything else more complex.