[fellowshipofone]

Thanks! In this last version, we decided to move all notions of channels (sms, push, etc.) to the classes. So each notification has a `trigger_name` linking it to the class form the @message decorator. So you can identify notifications that way, but you can't infer the channels they'll use.

[harshulj]

Got it now! But why was there a need of message decorator? The same task could have been achieved using the Channel Class.

[fellowshipofone]

The @message decorator allows transmissions scheduling logic not to have to be extended by your own code to focus on the actual Channel and Message logic. This way, the code is also magically indexing all the transmissions notification classes for when they need to be loaded asynchronously in the worker.

And if you meant that transmissions could have forced a couple of channel tasks, we would have missed the content of notification, the logic to check for validity, etc.