@Nuwan Yes the Notification interface will be generic and the Email Notification will be a implementations of. I thought that every tenant admin might not be able to access the configuration files thats why i planned to add UI in admin dashboard so that they can ad their email configurations through the UI.
@Shani Initially we planned to send notifications to the existing subscribers of an API. IMO all the subscribers must get the notification regardless of their role since they have already subscribed for that API. if there is any special use case where notifications should be sent to subscribers based on their user roles then as Nuwan Mentioned users can have their own implementation according their use case. @Chamin I agree with you if we have a way to subscribe for notifications then there should be way to unsubscribe notifications as well. Due to these reasons for the initial release we are planning to send the notifications only to the users subscribed to the particular API. @Chamalee I think the use case you mentioned will only affect when sending notifications during a new API addition and for the initial release we are not going to support this use-case. On Wed, Feb 10, 2016 at 6:51 PM, Chamalee De Silva <[email protected]> wrote: > Hi, > > +1 for Shani's idea. > > IMO better if admin have the control over the notification or some > mechanism to prevent notifying all the existing subscribers. > > As an example in a case where an API is created with visibility and > subscription-availability restrictions, notifying all the existing > subscribers should not be done or it may not needed. > > > Thanks, > Chamalee > > On Wed, Feb 10, 2016 at 5:32 PM, Shani Ranasinghe <[email protected]> wrote: > >> Hi, >> >> Since we share subscriptions, shouldn't we also allow the admin to decide >> to whom the notifications should go to? for e.g. For a certain API, for a >> certain event that occurs (e.g new version created), the admin might want >> to notify only the subscribers/ all in the group / to a selected group of >> users in the group by specifying email addresses. >> >> Also, are we firing the notification events right away when the event >> happens or is it like a scheduled task? >> >> >> On Wed, Feb 10, 2016 at 4:59 PM, Nuwan Dias <[email protected]> wrote: >> >>> @Sam, I think the notification interface should be generic. Meaning that >>> there should be a Notification interface and the Email notification should >>> be one implementation of it. There could be others such as SMS notifiers as >>> well. The email notification mechanism should have a way to define its own >>> parameters and any other mechanism should have provision to define its own >>> config params too. >>> >>> This is what we've done with workflows as well. And it's design gives >>> you the provision to plug it into any place you want. >>> >>> >>> On Wednesday, 10 February 2016, Joseph Fonseka <[email protected]> wrote: >>> >>>> Hi Janaka >>>> >>>> The examples that were given was just to highlight the fact that there >>>> are other places that notifications are valuable. Some are within the >>>> Store/Publisher Apps and others are from gateway/analytics. And as @Jaminda >>>> mention it is preferable to have single/similar/centralized configuration >>>> for all the notifications. >>>> >>>> Regarding the two alerts >>>> 1. Notify when a new API is added - If you take a site like >>>> programmable-web they support tracking of new APIs added to a selected >>>> category. Also if you look at in another angle sending an email might not >>>> be useful but *tweeting* about the new API can bring in value. >>>> >>>> 2. Notify when subscription is blocked - IMO this is a direct use case >>>> If you are an app developer you want to know if the subscription is blocked >>>> before users complain the app is not working. >>>> >>>> Cheers >>>> Jo >>>> >>>> >>>> >>>> On Wed, Feb 10, 2016 at 12:23 PM, Janaka Ranabahu <[email protected]> >>>> wrote: >>>> >>>>> Hi Jo, >>>>> >>>>> On Wed, Feb 10, 2016 at 8:34 AM, Joseph Fonseka <[email protected]> >>>>> wrote: >>>>> >>>>>> Hi Sam >>>>>> >>>>>> Few thought related to notification. >>>>>> >>>>>> 1. As I see notification can be a more generic use case not specific >>>>>> to notifying new API versions. >>>>>> Ex. Notify when a new API is added. >>>>>> >>>>> Is this really needed? IMO, we should not do this. >>>>> >>>>> The reason is that, IMO, all the users will not have a need to know >>>>> about the new APIs that are added. Even if we allow them to choose whether >>>>> to get notifications on new APIs, it is not useful practically. >>>>> Users will subscribe and use APIs based on their use-case and for an >>>>> end user, having a new API will not make them change their use-case and >>>>> re-implement what they have done. If a user needs a new API and a set of >>>>> new features, he/she would come to the store and search for a particular >>>>> API that matches their needs. >>>>> >>>>> Notify when subscription is blocked. >>>>>> >>>>> IMO, this is also not practical. If we are to do this, then we need >>>>> to have a mechanism of determining when to send an alert to the and to >>>>> whom >>>>> should we send the alert saying that their subscription is blocked. >>>>> Currently if the subscription is blocked, then we anyhow send that in the >>>>> response message. >>>>> >>>>> Thanks, >>>>> Janaka >>>>> >>>>>> Notify throttling limit reach. >>>>>> Notify when action related to workflow is performed. >>>>>> etc.. >>>>>> Thus when developing the notification component we should keep >>>>>> provision to support above. >>>>>> >>>>>> 2. As Amila pointed out we should provide an option to enable / >>>>>> disable notifications based on subscriber preference. >>>>>> >>>>>> Thanks & Regards >>>>>> Jo >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> >>>>>> On Wed, Feb 10, 2016 at 2:00 AM, Amila De Silva <[email protected]> >>>>>> wrote: >>>>>> >>>>>>> Hi Sam, >>>>>>> >>>>>>> Will the notification be pushed to all the Subscribers of an API, or >>>>>>> does the Subscriber have an option to select for which APIs they should >>>>>>> be >>>>>>> receiving notifications for? >>>>>>> >>>>>>> On Tue, Feb 9, 2016 at 7:26 PM, Sam Sivayogam <[email protected]> wrote: >>>>>>> >>>>>>>> Hi All, >>>>>>>> >>>>>>>> Currently in APIM when a publisher makes a new version of an >>>>>>>> existing api there is no OTB solution to notify the existing >>>>>>>> subscibers. >>>>>>>> >>>>>>>> Since there is requirement for this, we planned to introuduce a >>>>>>>> Notification Feature in the coming APIM release. This Feature will >>>>>>>> help the >>>>>>>> publishers to send a notification message to the existing subscribers; >>>>>>>> when >>>>>>>> they are making a new copy of an existing API. since most users prefer >>>>>>>> notifications to be sent through email, we will provide a default >>>>>>>> implementation which will notify the subscribers through email. >>>>>>>> >>>>>>>> What we are planning to do >>>>>>>> >>>>>>>> 1. Create a EmailNotifier class which will send notification emails >>>>>>>> to the existing subscribers. >>>>>>>> 2. Provide a Notifier interface which will help the publishers to >>>>>>>> create their own Notification implementations according to their >>>>>>>> requirements such as SMSNotification. >>>>>>>> 3. Create a admin dashboard page to add email configurations, these >>>>>>>> configurations will be saved in a registry and will be used by >>>>>>>> EmailNotifier >>>>>>>> 4. Add an option to select the Notify subscribers in the API >>>>>>>> copying page >>>>>>>> 5. Planning to Implement the EmailNotifier class using JAVA Mail >>>>>>>> API[1] >>>>>>>> >>>>>>>> Any suggestions and thoughts are highly appreciated. >>>>>>>> >>>>>>>> [1] http://www.oracle.com/technetwork/java/faq-135477.html#1 >>>>>>>> >>>>>>>> -- >>>>>>>> *Sam Sivayogam* >>>>>>>> >>>>>>>> Software Engineer >>>>>>>> Mobile : +94 772 906 439 >>>>>>>> Office : +94 112 145 345 >>>>>>>> *WSO2, Inc. :** wso2.com <http://wso2.com/>* >>>>>>>> lean.enterprise.middleware. >>>>>>>> >>>>>>> >>>>>>> >>>>>>> >>>>>>> -- >>>>>>> *Amila De Silva* >>>>>>> >>>>>>> WSO2 Inc. >>>>>>> mobile :(+94) 775119302 >>>>>>> >>>>>>> >>>>>> >>>>>> >>>>>> -- >>>>>> >>>>>> -- >>>>>> *Joseph Fonseka* >>>>>> WSO2 Inc.; http://wso2.com >>>>>> lean.enterprise.middleware >>>>>> >>>>>> mobile: +94 772 512 430 >>>>>> skype: jpfonseka >>>>>> >>>>>> * <http://lk.linkedin.com/in/rumeshbandara>* >>>>>> >>>>>> >>>>> >>>>> >>>>> -- >>>>> *Janaka Ranabahu* >>>>> Associate Technical Lead, WSO2 Inc. >>>>> http://wso2.com >>>>> >>>>> >>>>> *E-mail: [email protected] <http://wso2.com>**M: **+94 718370861 >>>>> <%2B94%20718370861>* >>>>> >>>>> Lean . Enterprise . Middleware >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> -- >>>> *Joseph Fonseka* >>>> WSO2 Inc.; http://wso2.com >>>> lean.enterprise.middleware >>>> >>>> mobile: +94 772 512 430 >>>> skype: jpfonseka >>>> >>>> * <http://lk.linkedin.com/in/rumeshbandara>* >>>> >>>> >>> >>> -- >>> Nuwan Dias >>> >>> Technical Lead - WSO2, Inc. http://wso2.com >>> email : [email protected] >>> Phone : +94 777 775 729 >>> >>> >> >> >> -- >> Thanks and Regards >> *,Shani Ranasinghe* >> Senior Software Engineer >> WSO2 Inc.; http://wso2.com >> lean.enterprise.middleware >> >> mobile: +94 77 2273555 >> Blog: http://waysandmeans.blogspot.com/ >> linked in: lk.linkedin.com/pub/shani-ranasinghe/34/111/ab >> > > > > -- > Thanks & Regards, > > *Chamalee De Silva* > Software Engineer > *WS**O2* Inc. .:http://wso2.com > > Office :- *+94 11 2145345 <%2B94%2011%202145345>* > mobile :- *+94 7 <%2B94%2077%202782039>1 4315942* > > > * <http://wso2.com/>* > -- *Sam Sivayogam* Software Engineer Mobile : +94 772 906 439 Office : +94 112 145 345 *WSO2, Inc. :** wso2.com <http://wso2.com/>* lean.enterprise.middleware.
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
