Thanks for the constructive feedback On Fri, Sep 27, 2013 at 10:36 AM, Mohanadarshan Vivekanandalingam < [email protected]> wrote:
> Hi, > > First of all, Thanks for giving some good feedback in user perspective. I > am sharing my thoughts in my point of view.. Please correct me if i'm > wrong.. > > On Fri, Sep 27, 2013 at 12:48 PM, Srinath Perera <[email protected]> wrote: > >> Playing with CEP 3.0, i feel we have taken backward step in terms of >> usability. >> >> Note I am not saying we should change this in the version we are putting >> out now, but fix it soon afterword. >> >> CEP 3.0 has introduced a processing pipeline that give users lot of >> flexibility. >> pipeline includes: event receiver, event builder, cep plan, event >> formatter, event sender >> >> This is great. Ideas come from Axis2 arch and we all agreed. >> >> However, CEP forces users to configure all parts of the pipeline all the >> time. >> Now users have to go though all the steps (and we do not have a wizard >> that guide you though :(). >> > > Whether execution plan wizard not helping for you to achieve this ?.. It > guide users to configure the flow.. Or whether we are missing anything > there.. > We did a minimum work on the wizard since we had time constrains. We can improve based on others suggestions. >> Problem 1: This is BAD idea, and this make life of the users very hard >> and force them to understand lot of new concepts. >> >> Axis2 has even bigger pipeline, but it does not ask at least one of the >> questions when you want to deploy a service. All extensions are hidden >> inside defaults and users will only see them if the want to extend the >> flow. If user do not >> know about them, still simple case is simple. >> > +1 for defaults > >> Problem2: Another key issue is while streams are core concept, there is >> no way to list all available streams or add them. >> > +1 we have to have a Stream UI, as we have already agreed > >> missongFollowing is my proposal to fix the problem. >> >> 1) Add default event listeners (e.g thrift) and senders and make them >> available out of the box. Others users may configure via Carbon configure >> view (not in main). Then even without configuring a listener, users can >> use thrift listener. >> > > +1, we have already discussed this matter and we have done some > development on this upto execution plan level, we have not touched other > parts because > it might break the flow at the release time and also it needs some design > level changes. We are going to focus on this with high priority for next > release. > For this release we'll make the local-ws-event listener, and thrift to be enabled in the pack & also figure out a simple Hello World like sample (a filter ) and make that enabled buy default. (like in AS ) I believe this will help to improve the usability. +1 for the idea of adding default event listeners (e.g thrift) and senders, here we need to have builders (by added streams from UI/ by the thrift client) and formatters (based on the defined streams on the system) configured automatically. > >> 2) In main menu, have only ExecuationPlan and Streams. Those are only >> central concepts. (E.g. In WSAS we have services and webapps here). When >> you creating new Execution plans, it is configured with thrift and data >> bridge formatters for default. Users can edit and change that. When they >> edit, then can either define formatters inline (they are not named .. and >> not added to list .. just like anonymous endpoints in ESB) or they can >> look them up from global list configured via Configure menu. >> > +1 to only have Execution Plans and Streams in main but I'm -1 for the idea of in-line formatters/builders, this is because it will enable users to create same formatters multiple times and that will reduce the performance at the execution, & it will also make the config language and the whole stream flow much complex and unmaintainable. E.g what happens it i defines an in-line formatter to Foo Stream, if a another plan outputs Foo will it be also using this?? & etc > +1.. > >> >> 3) Same for streams. But streams are always named. But they can add >> streams without leaving execution plan UI. >> >> +1 > +1, I think you have already mentioned regarding this.. Yes it good to > have a common UI to list the streams. > > Regards Suho > 4) In in deployment config files, we should support user to give >> anonymous event formatters and builders inline in the execution plan if the >> wish to. They can skip them altogether and then thrift default event >> formatters and builders are used. >> >> > Goal is to keep simple things simple. Now if I need to define a query, I >> say "Add Execution Plan", define streams inline, give the query and I am >> done. >> If I like to do complex things, I can do that too. >> >> > Yes, We can think about this but we needs to consider some important > things. As rajeev mentioned we can do it, in that manner but before that we > have to make sure that it will don't affect the sync between the > configurations. We needs to go through the design again and check how we > are going to achieve that but we can't allow tight coupling between the > components. Anyway I think, if we can complete the (1) and (2), then it > gives more clear way to achieve this.. > > Thanks & Regards, > Mohan > > >> Pls note we (including myself) did not catch this earlier. I am just >> trying to fix the problem, not to put down the nice architecture we have >> done with the pipeline. >> >> WDYT? >> >> --Srinath >> >> -- >> ============================ >> Srinath Perera, Ph.D. >> Director, Research, WSO2 Inc. >> Visiting Faculty, University of Moratuwa >> Member, Apache Software Foundation >> Research Scientist, Lanka Software Foundation >> Blog: http://srinathsview.blogspot.com/ >> Photos: http://www.flickr.com/photos/hemapani/ >> Phone: 0772360902 >> >> _______________________________________________ >> Architecture mailing list >> [email protected] >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *V. Mohanadarshan* > *Software Engineer,* > *Data Technologies Team,* > *WSO2, Inc. http://wso2.com * > *lean.enterprise.middleware.* > * > * > email: [email protected] > phone:(+94) 771117673 > > _______________________________________________ > Architecture mailing list > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *S. Suhothayan * Associate Technical Lead, *WSO2 Inc. *http://wso2.com * <http://wso2.com/>* lean . enterprise . middleware *cell: (+94) 779 756 757 | blog: http://suhothayan.blogspot.com/ twitter: http://twitter.com/suhothayan | linked-in: http://lk.linkedin.com/in/suhothayan* * *
_______________________________________________ Architecture mailing list [email protected] https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture
