Hi Senaka et. al, First of all, thanks all for your information & suggestions.
Apart for the things Subash has mentioned is there anything to be added or removed? Shall we arrange a meeting to discuss this further? Please suggest a convenient time for you. Thanks, Heshani On Mon, Aug 4, 2014 at 12:16 PM, Subash Chaturanga <[email protected]> wrote: > Hi Senaka et al, > In G-Reg mgt console, current notification types we have are > > - General: > resource Delete and Update > > - Lifecycle related > - check/uncheck LC item > - create/delete/state change in LC > - LC approvals > > *Service Provider; * > (It will be more like similar to what we had in mgt-console.) > > - All above types of notifications make sense for the provider and if we > support similar in service provider page , provider will subscribe to > interested events at his will similarly as in mgt console. Hence only what > provider want's to get notified will get notified. IMO provider also > should be able to subscribe to a set of selected services from provider > service list view. > > - In addition, provider should have a new event type called consumer-* > (consumer-comments/ratings/emails), and when service consumer added > comments to the service etc, the interested providers will get notified. > > - Option to send on the fly email notifications to service consumers(in > WSRR they allows to compose inline emails and send them on the fly for > consumers) > > @Senaka et al; please add/remove anything you feel right to what I > aforementioned. > > > *Service consumer;* > Service consumer is NOT the end user of the service(like the API > consumer), but the service consumer throughout the service development > period. > > - Comments/Tags/Ratings should generate events for notifications > - new Event type can be only seen by consumer, something like "service > provider messages" > - I am not sure about how LC related notifications types meaningful for > the consumer i.e LC Approvals. May be LC state change notification might be > useful. WDYT ? > > > > > > On Fri, Aug 1, 2014 at 8:55 PM, Senaka Fernando <[email protected]> wrote: > >> Hi all, >> >> So there are two parts related to this work. >> >> 1. Improving the Store itself to make use of the existing notification >> capabilities and extend it further for it to be more user friendly. >> SameeraJ is working on that. >> >> 2. The second part is to build the notification capabilities we want for >> Service Governance. This is typically what Heshani should be looking at. >> So, let me focus on that. >> >> Firstly, before thinking about the UIs involved and how to improve them, >> we need to think on what types of roles/groups of people would find it >> useful to have these notification capabilities. This also would help us >> determine their preferences as to whether an e-mail or a live-update in the >> system is going to be more useful. >> >> Next, not everybody might be interested in getting notified. So, just >> like we subscribe to consume an API, we need to subscribe to recieve a >> notification. Since the term subscribe can end up being a little confusing, >> we need to think about the best ways of combining or separating these two >> things. >> >> Also, the user of the Service Store is not an end-user, but an internal >> user, or someone who wants to get an understanding about the state of the >> running service. The word consumer means that they always use a service. >> This is true for those who consume APIs, but for services, I'm not sure >> whether that's the right term. >> >> So, as you might understand, before getting into the actual >> implementation details, we need to identify who is going to benefit out of >> these features and then start explaining requirements in terms of what they >> want to achieve. We can then decide on how and where to place these things. >> >> Thanks, >> Senaka. >> >> >> On Fri, Aug 1, 2014 at 9:21 AM, Subash Chaturanga <[email protected]> >> wrote: >> >>> Hi Ruchira, >>> +1 for sync up. We planned to push this by 5.0.0-M2. It will be end of >>> this month. >>> >>> >>> On Fri, Aug 1, 2014 at 12:36 PM, Ruchira Wageesha <[email protected]> >>> wrote: >>> >>>> Hi Heshani, >>>> >>>> If you can get the API ready initially, I think that would be the way. >>>> Then, from ES store and publisher side, we can use that API to >>>> send/retrieve notifications. >>>> >>>> @Subash, Heshani, >>>> >>>> What would be the timeline of this? Sameeraj has already started >>>> implementing notification support for ES. Hence, we need to sync up with >>>> you guys. >>>> >>>> /Ruchira >>>> >>>> >>>> On Fri, Aug 1, 2014 at 11:33 AM, Heshani Gamage <[email protected]> >>>> wrote: >>>> >>>>> Hi Senaka et. al, >>>>> >>>>> I'm implementing $Subject corresponding to the RM[1] .I would like to >>>>> verify requirements of this feature on following use cases. >>>>> a. Provide notification support for the Consumer side and Provider >>>>> Side >>>>> b. Support for notifications explicitly initiated from the provider >>>>> to a specific consumer/consumers >>>>> -For example after a certain bug fix, provider will explicitly notify >>>>> a certain set of consumers >>>>> >>>>> I need clarify following things >>>>> 1. How should the notification views be displayed on publisher and >>>>> store? >>>>> 2. What do we actually mean by a consumer/how should we identify the >>>>> consumer? (e.g.: e-mail address etc.) >>>>> 3. How to select specific consumers for b. above? >>>>> 4. From where should the provider initiate the notification in the b. >>>>> above >>>>> 5. As we already have notifications in G-Reg for a certain >>>>> extent, should display these notifications on the provider side too? >>>>> >>>>> >>>>> Is there anything to be added to the above? >>>>> >>>>> [1] https://redmine.wso2.com/issues/2342 >>>>> >>>>> Thanks, >>>>> Heshani >>>>> >>>>> -- >>>>> Heshani Gamage >>>>> Software Engineer, WSO2, Inc. >>>>> email : [email protected] >>>>> >>>> >>>> >>>> >>>> -- >>>> >>>> *Ruchira Wageesha**Associate Technical Lead* >>>> *WSO2 Inc. - lean . enterprise . middleware | wso2.com >>>> <http://wso2.com>* >>>> >>>> *email: [email protected] <[email protected]>, blog: >>>> ruchirawageesha.blogspot.com <http://ruchirawageesha.blogspot.com>, >>>> mobile: +94 77 5493444 <%2B94%2077%205493444>* >>>> >>> >>> >>> >>> -- >>> Thanks >>> /subash >>> >>> *Subash Chaturanga* >>> Senior Software Engineer & Lead WSO2 Governance Registry >>> Platform TG; WSO2 Inc. http://wso2.com >>> Contact: >>> email: [email protected] >>> blog: http://subashsdm.blogspot.com/ >>> twitter: @subash89 >>> phone: +9477 2225922 >>> Lean . Enterprise . Middleware >>> >> >> >> >> -- >> >> >> *[image: http://wso2.com] <http://wso2.com> Senaka Fernando* >> Software Architect; WSO2 Inc.; http://wso2.com >> >> >> >> * Member; Apache Software Foundation; http://apache.org >> <http://apache.org>E-mail: senaka AT wso2.com <http://wso2.com>**P: +1 >> 408 754 7388 <%2B1%20408%20754%207388>; ext: 51736*; >> >> >> *M: +44 782 741 1966 <%2B44%20782%20741%201966> Linked-In: >> http://linkedin.com/in/senakafernando >> <http://linkedin.com/in/senakafernando>* >> Lean . Enterprise . Middleware >> > > > > -- > Thanks > /subash > > *Subash Chaturanga* > Senior Software Engineer & Lead WSO2 Governance Registry > Platform TG; WSO2 Inc. http://wso2.com > Contact: > email: [email protected] > blog: http://subashsdm.blogspot.com/ > twitter: @subash89 > phone: +9477 2225922 > Lean . Enterprise . Middleware > -- Heshani Gamage Software Engineer, WSO2, Inc. email : [email protected]
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
