Hi Heshani, The developer and the operations roles seem to be a little overwhelming. For example, I feel its better to have a slight distinction between developers and testers so that they can request for specific lifecycle changes to be notified.
Also, the lifecycles do not begin with the development of a service and ends once it goes into production. There are some activities related to designing the service (these are mainly architects) and also deprecating the service (these are mainly managers and operations people). Also, a service can go through a bug fix cycle where developers, testers and ops are involved. Therefore, think a bit along these lines as well. We should have notifications once scheduled reports have been generated. Thanks, Senaka. On Wed, Aug 6, 2014 at 5:09 AM, Heshani Gamage <[email protected]> wrote: > Hi all, > > I did a small research on roles and notification types of existing > registry,repositories and came up with a set of common roles, and > notifications that might be useful to those roles. > Details can be found in the attached document[1]. > Please feel free to add/remove and edit entries. > Appreciate any suggestions to finalize a set of roles and notifications to > be added in the feature $subject. > > Thanks, > Heshani > > [1]. Roles and Notifications > <https://docs.google.com/a/wso2.com/document/d/10h5Q0ueIqvJUkGnPpLQYBNxd3gMAJOwDMzQwShMCtWs/edit?usp=sharing> > > Roles and Notifications > <https://docs.google.com/a/wso2.com/document/d/10h5Q0ueIqvJUkGnPpLQYBNxd3gMAJOwDMzQwShMCtWs/edit?usp=drive_web> > > > > On Mon, Aug 4, 2014 at 4:24 PM, Heshani Gamage <[email protected]> wrote: > >> 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] >> > > > > -- > Heshani Gamage > Software Engineer, WSO2, Inc. > email : [email protected] > -- *[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; ext: 51736*; *M: +44 782 741 1966 Linked-In: http://linkedin.com/in/senakafernando <http://linkedin.com/in/senakafernando>*Lean . Enterprise . Middleware
_______________________________________________ Dev mailing list [email protected] http://wso2.org/cgi-bin/mailman/listinfo/dev
