Help us to improve support for incoming messages

Look at mailhandler. Moshe might want to collaborate on some abstraction, to use the same set of tokens / codes to support various "Actions" in Drupal. Mailhandler creates new nodes, and we're doing with SMS receive today, so this shouldn't be a problem.

So, this helper module might be something like "Remote Actions" -- future versions of mailhandler could depend on it, and it could be extensible via a hook so people could expand the "vocabulary" available.

Also, it's more than just discriminators. We're using the # / hashtags to signify special keywords, which in and of themselves have logic attached. e.g. some options would be "support hashtags for group routing" and/or "support hashtags for taxonomy terms".

But yes, an actions tie in is likely the right way to go.

I have also been working on this (albeit quietly) for some projects we are doing at the MIT Mobile Experience Lab. My modifications are working and will be put to a live user test here in a few weeks.

I merged some of the SMS Receive module into the SMS core and then I implemented a hook_sms_action() which allows for modules to register their custom action keywords and callback functions, very similarly to how a custom Services module registers service methods in Services.module. I blogged a bit more explanation and an example usage just today.

I'm working now with MIT to figure out what exactly our next steps here are so that I can share my actual code (I've only been here a short time but it appears that there may be some extra process to go through to get the OK to release under GPL), but for now I thought it'd be good to say that I, too, am working in this area.

B.McMurray

Thanks for the feedback. I'll look at the mailhandler module. I like the idea of abstracting some of this into a separate module, but I'm wondering if it really makes sense as SMS commands and mailhandler commands won't be so similar. Mail message have a subject and body while SMS messages only have a short body that must be put under some pretty complex parsing logic.

I also like the idea of allowing symbols to identify specific variables in commands, as this avoids having to memorize a certain order for options. Parsing the proper variables out incoming message might be the biggest challenge, especially if we want admins to be able to configure completely custom commands.

I'd like to post what I have done so far in terms of Action integration and see if we can start a conversation around that. I think that this route will ultimately be the most flexible solution. My only worry is that there currently seems to be a shortage of actions out there. I understand that it's a new module but I'd like to be sure that there is going to be enough actions to trigger to make this worth it :)

I'll provide a link for a public sandbox once I have it up.

Thanks again for the feedback!

--
Will White

I've added my work on this to HEAD. The new module is called sms_actions. Here's a quick way to try it out:

1. Enable the sms_actions module.
2. Go to admin/smsframework/actions.
3. Add a command with the discriminator 'promote' and another with the discriminator 'demote'.
4. Go to admin/build/trigger/sms_actions
5. Assign the 'promote to front page' and 'remove from front page' actions to the respective discriminator.
6. Simulate a incomeing message by running the following function (devel module's PHP Execution Block is good for this):

sms_incoming('5555555555', 'demote [nid of a node on your site]');

I've added some API documentation about this. Let me know how it goes. Thanks!

--
Will White