+1 .. As you mentioned, we can create a generic UI for start/stop/status functionality, so task based implementations can use the generic UI rather than always creating that part from scratch. Then we've to come up with some convention to link a specific task type to the context specific UI. The concept of "task type" is already there in ntask, so just have to do the mapping.
Cheers, Anjana. On Fri, Feb 24, 2012 at 11:42 PM, Senaka Fernando <[email protected]> wrote: > Hi Tharindu, > > In effect yes. That's pretty much what's generic when it comes to tasks. > Something analogous (to a certain extent) would be the Windows Task manager > (the generic bit) compared with something like the Wrapper that we use to > start Carbon as a background process (the context-specific bit). > > Thanks, > Senaka. > On Fri, Feb 24, 2012 at 11:13 PM, Tharindu Mathew <[email protected]>wrote: > >> 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 <[email protected]>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 <[email protected]>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 <[email protected]>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 >>>>> [email protected] >>>>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>>>> >>>>> >>>> >>>> >>>> -- >>>> Regards, >>>> >>>> Tharindu >>>> >>>> blog: http://mackiemathew.com/ >>>> M: +94777759908 >>>> >>>> >>>> _______________________________________________ >>>> Architecture mailing list >>>> [email protected] >>>> 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 >>> [email protected] >>> https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture >>> >>> >> >> >> -- >> Regards, >> >> Tharindu >> >> blog: http://mackiemathew.com/ >> M: +94777759908 >> >> >> _______________________________________________ >> Carbon-dev mailing list >> [email protected] >> http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev >> >> > > > -- > *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 > [email protected] > https://mail.wso2.org/cgi-bin/mailman/listinfo/architecture > > -- *Anjana Fernando* Senior Software Engineer WSO2 Inc. | http://wso2.com lean . enterprise . middleware
_______________________________________________ Carbon-dev mailing list [email protected] http://mail.wso2.org/cgi-bin/mailman/listinfo/carbon-dev
