Return-Path: Delivered-To: apmail-jakarta-ant-dev-archive@apache.org Received: (qmail 39988 invoked from network); 20 Apr 2002 09:15:00 -0000 Received: from unknown (HELO nagoya.betaversion.org) (192.18.49.131) by daedalus.apache.org with SMTP; 20 Apr 2002 09:15:00 -0000 Received: (qmail 28421 invoked by uid 97); 20 Apr 2002 09:15:09 -0000 Delivered-To: qmlist-jakarta-archive-ant-dev@jakarta.apache.org Received: (qmail 28405 invoked by uid 97); 20 Apr 2002 09:15:09 -0000 Mailing-List: contact ant-dev-help@jakarta.apache.org; run by ezmlm Precedence: bulk List-Unsubscribe: List-Subscribe: List-Help: List-Post: List-Id: "Ant Developers List" Reply-To: "Ant Developers List" Delivered-To: mailing list ant-dev@jakarta.apache.org Received: (qmail 28394 invoked from network); 20 Apr 2002 09:15:09 -0000 Content-Type: text/plain; charset="iso-8859-1" From: Adam Murdoch To: "Ant Developers List" Subject: Re: [myrmidon] TaskListener and friends Date: Sat, 20 Apr 2002 19:18:00 +1000 X-Mailer: KMail [version 1.4] References: <200204162146.36510.peter@apache.org> <200204162248.07325.adammurdoch@apache.org> <200204201556.43383.peter@apache.org> In-Reply-To: <200204201556.43383.peter@apache.org> MIME-Version: 1.0 Content-Transfer-Encoding: quoted-printable Message-Id: <200204201918.00074.adammurdoch@apache.org> X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N X-Spam-Rating: daedalus.apache.org 1.6.2 0/1000/N On Sat, 20 Apr 2002 15:56, Peter Donald wrote: > Hiya, > > interesting questions (many of which I hadn't thought about). > > On Tue, 16 Apr 2002 22:48, Adam Murdoch wrote: > > Who is allowed to fire events? Can tasks? > > All services? A single service? > > Well not sure. I was thinking that it is only really necessary for the > Executor to have access to firing mechanisms. It would then call it at > start/end of task execution and it would also binf a stream to > System.out/err and have that stream redirect output as events. > Yep, this is better than the workspace firing them. Would we do away wit= h the=20 'project-started', 'target-started', etc events (since they can be implie= d=20 from the task events)? How would we distinguish between events from the = same=20 task being executed in different execution frames? How would the input stream deal with async. execution? Same as ant1? If= so=20 we probably want some way for a task to attach whatever extra threads it=20 spins up. > > * How does a listener get registered? How does a task register a > > listener? Or an app? Or a service? > > No idea. Maybe another service? > Sure. Makes scoping simpler, and would allow the event infrastructure to= be=20 made more general later on. > > * Are events scoped? That is, are they visible outside the execution > > frame where they were fired in? In parent frames? Child frames?=20 > > Globally? Depends on the listener? > > Not sure. Scoped listeners sound interesting. You add a listener at a > specific ExecutionFrame and all events below that gets delivered - I li= ke > that. Of course we would need an escape mechanism that said add this to= my > parents frame (ie to change verbosity of a target) or top-level frame (= ala > project listeners) or whatever. > Perhaps as a separate service interface, so that we can restrict access t= o it. > > * How are events typed? Are the types extensible? Can we fire, say, > > 'external command started' or 'type registered' events for inter-serv= ice > > communication? > > I was thinking they are less a communication system and just notificati= on > about event execution and thus the even should be final. However if we > wanted a command bus maybe we could build another system. True. Forget that idea for the time being. --=20 Adam -- To unsubscribe, e-mail: For additional commands, e-mail: