Hi all, I promised a while ago to provide a rough roadmap for development of the SMS Framework suite of modules. Here is what I have so far.
I have been through the enormous issue queue and have collected a list of requests (bugs, features, etc) to factor in. I also had a meeting with Will White in January about this, and I am doing my best to include his ideas and intentions, as with derhasi's previous group post about 6.x-2.0.
I hope that this information gives you a good idea of the current intentions, but feel free to contribute ideas and feedback (criticism welcome) - this is a user- and contributor-led project, so your thoughts are our most valuable asset. There are also several awesome people who have stated that they would like to help with the effort - this is welcome and tasks will be delegated depending on what people would like to do.
Please find a summary of the roadmap below, plus the full roadmap on the external website in this link: http://moo0.net/smsframework/?q=node/1 - I intend to provide an external website (proper domain name to be established) for anything that we might not be able to put into drupal.org - development information, extended documentation, gateway module repository and community acceptance status, plus gateway voting and advice. (I now realise that I could use a wiki page in the Drupal Groups.)
As a rough outline (full version here: http://moo0.net/smsframework/?q=node/1 )
- Halt further development of the 5.x releases (bug-fix only).
- Bug-fix release for the 6.x version, to clear as many of the 1.x bugs as possible, add email gateways and provide CRUD UI.
- Issue better guidelines for gateway module development and a user-acceptance process for faster inclusion and adoption.
- Begin to include SimpleTest unit testing into the core modules and recommend expansion into user-contributed modules.
- Release 1.1: bugfixes, gateway return codes, message archiving, dev tool, intl number validation improvements, CRUD UI for email carriers, core module suite improvements.
- Release 2.0: gateway receipts, message queueing/scheduling, message limits, improved international number handling, extended gateway module capabilities, dynamic selection of gateways, improved complimentary module integrations (rules, actions, triggers, tokens, etc).
- Future: 100% rewrite due to PHP 5.2+ adoption and (near) universal acceptance of PHP classes in Drupal projects. Object-oriented architecture, which will be much easier for anyone developing futher capabilities for these modules.
- Release for Drupal 7.x...
Also, about the external website
- Hosting for gateway modules (similar to Ubercart) with download stats and thumbs-up/thumbs-down voting to give newcomers an idea of user experience for each gateway module.
- Gateway (SMS aggregator) company reviews/advice.
- Up-to-date lists of email_gateway carriers (that can be imported into the carriers DB table).
As I said, this project needs your feedback, whatever it might be. Please provide feedback to this posting - there are no comments on the external site yet.
Thanks everyone,
~aspope
Comments
Feature request / feedback
hi,
like the idea of dynamic gateway selection - are you thinking least cost routing, or MSISDN-based gateway selection? Based on past experience LCR can be a PITA to administer (although a nice marketing point). One thing I would like to add to that is support for managing prepaid gateways, with current balance stored in database.
My site setup at the moment is using Organic Groups, smsbulk, sms_user and notifications/messaging: OG notifications are doing the equivalent of sms_blast to groups, smsbulk to allow individuals to be targetted. What I'd like to see is a single, centralised logging point for all messages - at the moment I've got some logging from smsbulk, some from the gateway; having a single database with an append-only table for auditing would help out. I've started to put that together, so if it's of interest am happy to share but I'm sure someone better at coding than me would do a better job.
In terms of integration with other modules, location seems a natural one to look at: there are quite a few possibilities created by integrating "find me" via SMS and 'find the nearest ... ', and also just web-based "find my nearest" accompanied with texting?
Let me know if I can help, possibly more use with the website than I would be with coding newer versions ;-)
Dynamic gateway selection, Logging, Locations
Thanks @andybill. Will call on you for help with the site, pending the green-light.
With regard to dynamic gateway selection, I would imagine using a kind of points-based system that would allow multiple factors in the routing decision, eg: least-cost, location, preferred reply-to number, etc. You are right - I can see this turning into a can-of-worms that could be difficult for users at first, but I'd love to try because it is in demand and is a great selling point, as you said.
I think that many of us have written message logging functions :-) - I have one that I think is good and flexible that I would like to put up for consideration.
About the location stuff - do you know how many SMS aggregators will provide coordinates or cell information? I understand that operators hold on to this stuff pretty closely, and in many countries it counts on the user's opt-in.
@aspope
your logging functions will be better than mine :) seriously though, there should be a standardised, auditable (ie WORM) trace for all messages.
As I think we've agreed LCR can be a complete nightmare: I've got some LCR stuff that was designed for PSTN routing but the main issues people will have are likely to be administrative / policy decisions rather than straightforward numerical ones: for example, if GatewayA is 5% cheaper than GatewayB for a given destination, but it requires a threefold increase in any prepayment or deposit, that can't be a technical decision; having said that, the technology needs to provide the info to the decision makers - which is where centralised logging comes back in. :)
In terms of location gateways, there are a few - not many, like you say most operators sit on that sort of info, as they don't want anyone else making money that they could keep for themselves - but they exist, and being one of the first to be integrated with SMS Framework might get one or two more SMS gateway companies (especially smaller ones) to look into location gateway-ing.
They already have interconnects, after all ... Most of those companies provide the info in HTTP(S) calls rather than as SMS or SMPP, so perhaps the receipt listener could be extended to incorporate other formats? I'd say this is probably a seconday area compared with e.g. logging and gateway selection.
Locations etc
Cheers @andybill. You have already reminded me that MX Telecom offer location services in the UK. If implemented, locations would definitely be an add-on module which could very well be implemented in parallel with the SMS Framework. However, it would be good to build a locations core to ensure that a common set of functions exist for anybody who wants to create their own unique solution, and to perhaps extend upon any geo modules that may already exist.
I see we are now talking about LCR in PM - suffice to say there is a lot to discuss! It's awesome that you have experience with this though.
Inbound messaging
I like the DevelopmentSeed approach of parsing taxonomy to extract a location by name: that could be extended to become a generic "keyword grabber" with some kind of form to let end users create their list of taxonomy terms for keywords (without having to know what taxonomy means). The same approach could be extended to enable voting, blog posting, whatever ...
If a similar approach is used with location info - provided a common core set of fields can be extracted from whichever gateway - then inbound location info can be used to trigger a ruleset (which could in turn trigger outbound messages). Might be necessary to implement some more complex logic in code, but I'm sure a lot of the things most people would want are achievable using views, view bulk object (possibly executed by an action) and rules. A different content type for each sort of inbound message may be over the top, but it might also make some things easier: with a content type of mobile_location, for example, it'd be really easy to then execute a view to determine the nearest "X" (ATM, postbox, whatever) and for site owners to start offering those services to their customers.
number validation
not sure if this is something for the SMS Framework, or it's a site-specific thing. The ability to validate a mobile number would be handy: for example, the admin for one of the sites I've been working on recently imports users to a group each month to determine who to txt with that month's promo. The imported mobile number goes into a profile field. Cheating slightly, I have a MySQL procedure synchronising sms_user and profile_values.
What I did not count on - and should have allowed for - is that some of the supposedly UK-based "mobile" numbers that were provided were actually Irish mobile numbers, some were UK landlines, and one enterprising person provided a £1/min premium rate line as their contact phone number. I've intercepted the MySQL sync process to handle most scenarios, but I just don't really like the idea of doing this using triggers and procedures - it would be neater if the framework had a "validate number" option/module, that wouldn't break database independence. Number portability means it's probably not worth trying to break down by network, unless a specific need exists and therefore a paid service could be used (e.g. MX's network lookup), but you could have a generic "is it a mobile or not" validation, and then a "which network is it on ($$)" option? In terms of handling international number formats, a regex can take out the really silly, then we'd need people to "chip in" with country-specific rules. I guess we'd end up with tables for handling country-specific mobile vs fixed line validation - but that plugs in with the LCR stuff, and common core data could be used.
On the other hand, would this be complexity for complexity's sake? How many other people need similar validation? LCR can't work unless you know to which network you're sending, but is LCR really necessary for SMS?