Incoming functionality of SMS Framework has some quirks. This issue aims to tweak things a little.
Determining if plugin supports incoming
Framework uses instanceof to determine whether a gateway plugin “supports incoming”. This requires an instance of the gateway to be created.
Change “supports incoming” determination to a annotation property. This property is informational only.
This annotation should not be used to automatically create an incoming route in the future.
Plugin incoming method
When you feed a message to SmsProvider::incoming, there isn’t really a pre- and post- process of the message. Officially its post-.
Introduce meaning to the SmsGateway::incoming method wherein it is the middle event. Thusly there is a reason to have a pre- event.
Rename the existing SmsGateway::incoming to SmsGateway::incomingEvent. The functionality of this method will be changed to be that it represents the event that always happens in between pre- and process- incoming events.
This method is optional.
Parameter for incomingEvent is an event object, not a SMS. There is no return value.
Note: logic for handling the incoming request does not happen in this event.
Mark SmsGateway::incoming as deprecated, remove in next release immediately since annotation is a breaking requirement.
Enforce result and reports
(this should also be done for SmsGateway::send
Ensure when SmsGateway::incoming (or SmsGateway::queue with incoming) receives a message:
- A result is set on the message (via
SmsMessage::setResult). - A report within above result object exists for each recipient on the message.
Throw an exception if any of the above conditions are not met.
Incoming enforcement should happen in a first class event subscriber responding to pre-incoming.
Outgoing enforcement should happen in a first class event subscriber responding to post-outgoing.
Effects
To implement a plugin with incoming functionality, set supports_incoming annotation to TRUE. There are no longer required interfaces/methods.
| Comment | File | Size | Author |
|---|---|---|---|
| #14 | incoming-tweaks-2832601-14.patch | 37.19 KB | dpi |
| #9 | incoming-tweaks-2832601.patch | 36.2 KB | dpi |
Comments
Comment #2
dpiComment #3
dpiComment #4
dpiComment #5
almaudoh commentedThe whole "incoming" thing is something I'm still trying to understand really. It is an artifact from the old D6/D7 versions.
Ideally, if we want to use SMS Framework to provide processing for incoming messages, the likely way that would happen is in a callback route linked to the gateway just like in the delivery reports.
Have you actually made use of incoming in any of your projects?
Can you clarify this?
::incoming()actually has the same pre- and post-process events dispatched as::send()and::queue()Comment #6
dpiI think so too. But for now it is easy enough to DIY: I outlined steps in docs.
Not yet.
I am investigating the process of implementing incoming and how it passes through SMS Framework for SMS Twilio (#2829760: Implement incoming messaging functionality) and Clickatell.
The existing events don't change at all. Its only re-defining what pre- and post- surrounds: the middle process. For outgoing its gateway::send(), but when you are receiving a message it is _____. ie. no pre-.
Comment #7
dpiAn alternative is removing the pre- events for incoming.
Comment #8
almaudoh commentedThere might still be use cases for a pre- process event. It depends.
Comment #9
dpiReady for review, PR: https://github.com/dpi/smsframework/pull/60
Travis is green, patch should pass here.
Commit log
Comment #10
dpiChange record
\Drupal\sms_test_gateway\Plugin\SmsGateway\Memoryfor an example.SmsGatewayPluginIncomingInterface— it no longer existsComment #11
almaudoh commentedMade some comments on the PR. This is really more of moving code around than anything else really.
Comment #12
dpiAddressed some nits in PR review.
What do you think about the interface naming still? (PR comment)
Comment #13
almaudoh commentedMade a new comment on the PR. The new name still misses 'Processor' or 'Subscriber' which I think is key to understanding at a glance what that interface should represent.
Comment #14
dpiAddressed remaining review nits.
For PR commit 957cf521e24a2ad35d4132768b2c1f5348a6dcb9
Comment #16
dpiCommitted.
CR at https://www.drupal.org/node/2836073
Comment #17
almaudoh commentedGreat work!!