Do you mean something like a task manager/monitor UI. functionality: Start, stop tasks, list running tasks...
On Fri, Feb 24, 2012 at 10:25 PM, Senaka Fernando <sen...@wso2.com> wrote: > Hi Tharindu, > > Well, there is a slight relevance, and hence this e-mail. Take the service > UI for example. Multiple products publish multiple kinds of services which > have different semantics, but utilize a single UI. And, another example is > a situation as in G-Reg. There can be multiple types of tasks that may get > scheduled even in a single product. I'm not suggesting a 100% generic UI, > but I'm trying to understand the best solution to this situation. While we > can write our own thing is an easy answer. How can I manage, understand and > correlate all my tasks is definitely going to be a question to a user in > the long run. > > Thanks, > Senaka. > On Fri, Feb 24, 2012 at 9:56 PM, Tharindu Mathew <thari...@wso2.com>wrote: > >> BAM will also use ntask quite soon, and what you say applies. The context >> of a task varies greatly. >> >> So having a generic UI has no meaning if the context of tasks are >> different, does it? >> >> On Fri, Feb 24, 2012 at 9:29 PM, Senaka Fernando <sen...@wso2.com> wrote: >> >>> Hi all, >>> >>> The ntask component, done by Anjana, is very useful to schedule any type >>> of task based on Quartz. I got G-Reg to use this, and (except for exception >>> handling which is totally not useful, :-)..) it is great. But, DSS which is >>> the only other product apart from the next release of G-Reg which uses >>> ntask has its own UI. G-Reg and any other product starting to use ntask >>> would love to have a UI to manage it, and a UI-per product is definitely of >>> least use. The proposal I'm making here is to drop the existing DSS task >>> scheduling UI and design a new one based on ntask, that is generic such >>> that more than one product can make use of it. >>> >>> But, there is a slight catch here because task scheduling can have a >>> different meaning from product to product. In DSS the use-case is DSS >>> invocation. In G-Reg some usecases are report generation and >>> change/lifecycle management. So, a proposal from Isabelle was to create a >>> generic task thing and link the context sensitive scheduling interfaces >>> (i.e. the Reporting UI that we are planning for G-Reg) with that. >>> >>> Your feedback is most appreciated. >>> >>> Thanks, >>> Senaka. >>> >>> -- >>> *Senaka Fernando* >>> Product Manager - WSO2 Governance Registry; >>> Associate Technical Lead; WSO2 Inc.; http://wso2.com* >>> Member; Apache Software Foundation; http://apache.org >>> >>> E-mail: senaka AT wso2.com >>> **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 >>> Linked-In: http://linkedin.com/in/senakafernando >>> >>> *Lean . Enterprise . Middleware >>> >>> >>> _______________________________________________ >>> Architecture mailing list >>> architect...@wso2.org >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Regards, >> >> Tharindu >> >> blog: http://mackiemathew.com/ >> M: +94777759908 >> >> >> _______________________________________________ >> Architecture mailing list >> architect...@wso2.org >> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >> >> > > > -- > *Senaka Fernando* > Product Manager - WSO2 Governance Registry; > Associate Technical Lead; WSO2 Inc.; http://wso2.com* > Member; Apache Software Foundation; http://apache.org > > E-mail: senaka AT wso2.com > **P: +1 408 754 7388; ext: 51736*; *M: +94 77 322 1818 > Linked-In: http://linkedin.com/in/senakafernando > > *Lean . Enterprise . Middleware > > > _______________________________________________ > Architecture mailing list > architect...@wso2.org > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- Regards, Tharindu blog: http://mackiemathew.com/ M: +94777759908
_______________________________________________ Carbon-dev mailing list Carbon-dev@wso2.org http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
