Posted by derhasi on May 6, 2009 at 10:40am
Jump to:
| Project: | SMS Framework |
| Version: | 6.x-2.x-dev |
| Component: | Core Framework |
| Category: | feature request |
| Priority: | normal |
| Assigned: | Unassigned |
| Status: | closed (won't fix) |
Issue Summary
In most cases sms messages should be handled in Drupal to execute or extract any information, it's important to save the messages in a general way. For being able to direct to a special message by simply calling an message-ID, there has to be central database storage.
So I started to write a new submodule for that issue, depending on #442748: New hook system with hook_sms() for 2.x.
Database-table:
- mid
- direction
- type
- text
- sender
- recipient
- sms (whole serialized $sms-object)
In .install there weight will be set to -2, to assure modules can call $sms->mid when calling hook_sms(post send) or hook_sms(post receive). So additional storage may be possible, like saving a $sms <-> $user relation.
You're welcome to add comments.
| Attachment | Size |
|---|---|
| sms_dbstorage.info | 189 bytes |
| sms_dbstorage.install.txt | 2.27 KB |
| sms_dbstorage.module.txt | 2.83 KB |
Comments
#1
A quick comment from a 1.0 user, without having done much analysis.
Please consider coordinating this with the Messaging Framework, which already stores messages if my memory serves me right. Some people already use the messaging_sms module that comes with Messaging.
#2
messaging_store, a Messaging table:
- mqid
- uid
- sender
- method
- destination
- subject
- body
- params
- created
- sent
- cron
- queue
- log
#3
Where message storage would be handy is when you want to wait for confirmation that a message is sent and if there is a failure then you can attempt to resend or resend via a different gateway. In this case using messaging is probably not going to be solution since not all sms are sent via messaging, so the sms module needs its own queue.
The new sms_track is a new module that aims to cater for this issue so make sense to focus effort there.