Posted by derhasi on June 19, 2009 at 8:48pm
After starting a patch for providing an extended new hook system in v2 (http://drupal.org/node/442748), I corresponded with Will to start efficient planing of the 2.x branch by introducing some main goals for development. You are welcome to join the discussion and leave proposals.
SMS Framework will be stated "on heavy development" so should not be used on production sites at the moment.
This list might grow in the next days, so feel free to propose new points or comment on existing ones.
- New hook system for sending and receiving messages
hook_sms() - with ops:pre send, send, post send, pre receive, receive, post receive (more in http://drupal.org/node/442748) - Rewrite existing modules to fit new hook system
- SMS as object ($sms)
- Extended gateway handling:
- selectable gateways for different dependencies (country, user account, sms type)
- cost management/logging
- Gateway as object ($gateway)
- overall sms types (like Default, Long message, Flash-SMS, MMS)
- SMS logging and storage
- Testform for simulating sending and receiving sms for test issues
- Automated node creation (sms mapper)
Categories: rewrite, sms, smsframework
Comments
Yes! MMS support :)
I'd like to help work on MMS support. I'm already using SMS Framework to send/receive MMS messages but it did require some custom modules. Here are some related issues: http://drupal.org/node/373307 and http://drupal.org/node/490890
Location based services
I am not a specialist on how the telco's share location with SMS providers, but perhaps others are.
It would be real cool to be able to receive SMS senders location (with all authorisations etc). Either in the inbound SMS or through callbacks.
Are there people who know if there are any industry standards in this regard that we could take into account in the design at least?
I suggest to include this
I suggest to include this feature http://groups.drupal.org/node/21232 .
Sender ID
I suggest to append to the gateway config a list of available/enabled sender ID.
A default one should be keeped.
A list of available sender id could be used to impose a sender id between those available on specific case, or let the choice to the user sending the message.
Char Codings
I would also filter the outcoming message character codings.
Giving the options of using GSM 03.38 (140 8-bit characters) or UTF-16 (70 16-bits characters). Or limiting to the GMS 03.38.
Giving a preview of the resulting message before sending.
Multiple recipients and gateway return codes
How about selecting default and backup gateways, or even better, for paralleling of gateways when the load is too much for one gateway.
I'm currently working on a bulk sms site at pluralsms.com and I'm seeing a number of deficiencies in the SMSFramework 6.0-1.x. Like:
I can't send to more than one number at a time because sms.module's sms_formatter() cleans out all non numeric characters before sending, unless I make my own form. I did a workaround for this in my infobip gateway module http://anieanie.com/downloads/custom.zip by creating another textfield for 'numbers' (comma-separated list of numbers) which will come through to the gateway via $options
I don't get critical response from sms_send() (like the message ID's from my provider) because sms_send's sms_handle_result() call doesn't allow the response from my gateway to get to the code calling sms_send. So I don't know which numbers were successful and which were and which messageID's to use to get delivery reports. Can you allow the provider response to get all the way to the sms_send call.
Hope d new version will fix these issues. Meantime, what do I do about 2) above. Can send in a patch if you like.
patches
Patches in general are always good.
The best way forward is to open 2 issues in the issue queue for this. If you have a patch that you think works for everyone, then posting it there is a great idea.
Personally, I think the 2d issue is more genericly imortant than the 1st. The issue queue is a great place to discuss this.