New hook system with hook_sms() for 2.x

I agree, using a general $message object would be the best method, so any module can add its own necessary information. Besides I also suggest a $gateway object, that will contain the $gateway->type and additional options, like ->uri / ->user / -> password.

So $message could contain

->message
->sender
->recipient
->gateway (object)
->type
->direction (outgoing / incoming)
->...

If this approach should be realized, we should think about legacy to existing sms.module implementations.

Is 2.x-dev the place for adding this functionality?

I would start tonight with writing some changes to 2.x-dev implementing send:pre process/process/past process

My suggestion for the hook-ops would be:

pre send process
- collect all information for $message (except gateway dependent)
- validate message in basic

send process
- will be performed before the original _send-function of the given gateway
- will only change $message->gateway - information
- will validate only gateway-dependent cases (like, user may not send via gateway A, but may send via gateway B)

post send process
- will handle suffescully sent or failed messages
- may save a message to database
- may fire status messages
- may create new content (like nodes)
- ...

My suggestion for a minimum $message-object would be:

$message ->
type ^(string)
- type definition (e.g. by module) - like "sms_blast", "node_link", ...
mid ^(int)
- serial for outgoing AND incoming messages
direction ^(string)
- either 'out'(sending) or 'in'(receiving)
recipient ^(integer?)
- the international number for messages (without +, without whitespaces)
sender ^(integer?)
- the international number of the sender
message ^(string)
- the to send message
gateway ^(object)
- the gateway object should at least contain the 'type' attribute

Should be introduced a new hook for legacy reasons?
(1) hook_sms($op,$message)
(2) hook_sms_alter($message,$op)
(3a) hook_sms_incoming($op,$message)
(3b) hook_sms_outgoing($op,$message)

I would favourize (1), so we could secure only gateway may be edited (and maybe recipient & sender).

I would propose that any module that uses sms.module to send an sms has to define ->type itself, like node_save(), that has to have a $node->type defined.

For legacy I would add the opportunity to internally keep opportunity (1)sms_send($number,$message,$options=array()) but define it as (2)sms_send($message,$a1 = NULL, $a2 = NULL) and switch to (1) if $a1 is given as a string. $message->type then would be set to 'legacy'.

hook_sms($op, $message)

OPs:

• pre send
• send
  may call hook_sms_send via sms_legacy_sms("send",$message) in a sms_legacy.module
  after that op the gateway_send will be called
• post send
• ---
• pre receive
  may call hook_sms_incoming("pre process") via sms_legacy_sms("pre receive,$message) in a sms_legacy.module
• receive
  may call hook_sms_incoming("process") via sms_legacy_sms("receive,$message) in a sms_legacy.module
• post receive
  may call hook_sms_incoming("post process") via sms_legacy_sms("post receive,$message) in a sms_legacy.module

There could be a sms_gateway.module, that will add the default gateway in sms:pre send, if there's none given. But for the first steps, I try to use the given gateway handling.

If you have any suggestions, you can contact me via IRC ;)

built a first patch on sms.module and sms_legacy.module

Changed $message - object to $sms-object to avoid legacy confusion.

Also changed sms_send_log() to fit in new gateway_send.

Changed some minor errors (e.g. an error logs were sent falsely).

Applied the patch on the current dev.

recognized a bug in the patch, please replace $sms->text = $a2; with $sms->text = $a1; in sms_send().

I will include it in a patch file soon, after I've discussed with Will about further steps.

Yes, implementing messaging as dependency might be a solution. Personally I have to take a closer look on that module.

Integration to messaging would be a more generic way, I guess. But I hadn't had enough time to have a closer look on it :(