Before we all get side tracked. I just wanted to make clear that my examples about distributed execution or optional dependencies were just to illustrate what declarative programming tries to acomplish.
I am not advocating anything, at this time, on this lines. Jose Alberto > -----Original Message----- > From: David Jencks [mailto:[EMAIL PROTECTED] > Sent: Wednesday, March 28, 2001 7:11 AM > To: [EMAIL PROTECTED] > Subject: RE: What is a 'declarative' language > > > ..distributed build tool.... > > Hope you don't mind me jumping in with a comment.. > > I haven't thought about it much yet, but it seems to me that > a very elegant > distributed build tool could be made using JINI/javaspaces. > I'd imagine > you'd have javaspace entries for the targets, and for the > tasks. You'd > have deployed objects for each task, and for each target. > You'd need 2 way > communication -- when you pick a build target, you'd add an > "I need this > target" entry to the space: each target would be looking for > a request for > its services, and when it finds a request, would request the > targets it > depends on. When a target completes, it would add entries > describing the > completed work, which the depending targets would find and > start on. I > think this gets by with a minimal and generic controller that > doesn't need > to know itself anything about the dependencies-- mostly it > decides how many > of what workers to put where (after translating XML into entries). > > I'm also not sure exactly how this relates to 'declarative' > > Just an idea > > David Jencks > > On 2001.03.27 05:07:33 -0500 David Bullock wrote: > > On Tue, 27 Mar 2001, Tim Vernum wrote: > > > > > I'd like to see list/set based operations. But I like them because > > > they're a fairly clean, simple, and powerful way of supporting > > > iteration, not because they're declarative. > > > > > > > Point taken. :-) > > > > The request for 'declarative' comes from people who wish to > attempt to > > parallelise execution of Ant tasks in a distributed ( > multi-machine / > > multi-OS ) fashion. > > > > I think the contention is that, if the dependency graph cannot be > > determined by each execution context at startup ( which is > the benefit of > > a purely declarative language ), then it makes the task of > implementing > > this more difficult. > > > > Without thinking too much about it yet, there seem to be two basic > > approaches to 'distributed ant' possible here: > > > > 1a) a 'controller' antd process invokes the task-building > services of > > various other antd's ... that is, the controller knows what the > > dependency graph is, and simply farms out work at a > task-atomic level. > > > > 1b) as for 1a, except that chunks of the dependency graph > are farmed out > > at a time (non task-atomic) > > > > 2) a set of antd services is given a build-file to build, > and a pointer > > to a shared BuildState kept in JNDI ( or something like that ) > > > > > > Intuitively, model 2 seems more flexible. Not sure what > the benefits of > > knowing the dependency graph at startup would be. > > Model 1a doesn't seem to have any special requirements for > the dependency > > graph to be known at startup. > > Model 1b would require the dependency graph to be known at > startup, and > > not to change. > > > > > > I really think the 'declarative' discussion is up to the > people who want > > to do 'distributed ant' sometime in the future. What are > the constraints > > on the buildfile language that would really be showstoppers if not > > observed? > > > > > > ( I should add that, in the multi-tool world of Java, it is > important to > > be able to do distributed builds on different underlying OS's ) > > > > > > > > regards, > > David. > > > > > > Thanks everyone, for Ant! > > > > > > David Bullock > > LISAsoft Project Lead > > Sun Certified Programmer for the Java 2 Platform > > > > email: [EMAIL PROTECTED] > > mobile: +61 4 0290 1228 > > > > "The key ingredients of success are a crystal-clear goal, > > a realistic attack plan to achieve that goal, > > and consistent, daily action to reach that goal." > > > > Steve Maguire, "Debugging the Development Process". > > > > LISAsoft > > http://www.lisasoft.com/ > > > > Adelaide Sydney > > -------------------- ------------------------ > > 38 Greenhill Rd Level 3, 228 Pitt Street > > Wayville S.A. 5034 Sydney NSW 2000 > > Australia Australia > > > > PH +61 8 8272 1555 PH +61 2 9283 0877 > > FAX +61 8 8271 1199 FAX +61 2 9283 0866 > > -------------------- ------------------------ > > > > >
