Transmissions, for Django

#1

Post by fellowshipofone » Sat, Sep 05, 2015, 6:33 PM UTC

Re: Transmissions, for Django

#2

Post by harshulj » Sat, Sep 05, 2015, 6:55 PM UTC

This is really helpful. I might even use this in my next product.

One question though, I don't see a 'type' field in Notification class. Won't it be helpful if notification type can be saved to identify if the notification was an email notification or push notification and so on?

Re: Transmissions, for Django

#3

Post by fellowshipofone » Sat, Sep 05, 2015, 7:11 PM UTC

harshulj wrote: post #2

This is really helpful. I might even use this in my next product. One question though, I don't see a 'type' field in Notification class. Won't it be helpful if notification type can be saved to identify if the notification was an email notification or push notification and so on?

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.

Re: Transmissions, for Django

#4

Post by harshulj » Sat, Sep 05, 2015, 7:38 PM UTC

fellowshipofone wrote: post #3

harshulj wrote: post #2

This is really helpful. I might even use this in my next product. One question though, I don't see a 'type' field in Notification class. Won't it be helpful if notification type can be saved to identify if the notification was an email notification or push notification and so on?

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.

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

Re: Transmissions, for Django

#5

Post by fellowshipofone » Sat, Sep 05, 2015, 9:35 PM UTC

harshulj wrote: post #4

fellowshipofone wrote: post #3

Earlier quoted context omitted.

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.

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

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.