At 10:55 10/4/01 -0700, David Rees wrote: >>I am not sure why you think such a system would be simpler. Aspect based >>systems are meant to be used to give fine grain separation of concerns. How >>the aspects are handled (ie Facilities in my terminology) is not set. In >>essence what you propose is to reclump all aspects into one again and then >>swap out facilities at runtime (ie essentially what Ant1 does with it's >>magic properties/loggers). >> >>This of course fails to provide for large projects who want need the extra >>flexibility to do their own thing. It also doesn't add anything on an >>aspect based system because we could always directly configure facilities >>to provide appropriate fgeatures (ie special ClassLoaderFacility for GUMP >>builds, BlameFacility for Alexandria, DocFacility for AntDoc etc). >> >>So I can't see how it is simpler or more useful for the **users** (though >>it would be simpler for us Ant developers). >> > >I think are concepts are the same and its more of an API question >rather than one of aspect orientation. As a big proponent and someone >who has coded aspects into the compiler in those languages that I >could (Smalltalk) I don't think I am arguing against aspects. In fact, >in my experience, most aspect oriented solutions are not visible in >the code at the point where they are used. Instead, they are >installed/uninstalled as part of that classes configuration.
right. With this I agree - the namespaces proposal for aspect handling should not pass in configuration data for the Facility (or AspectHandler). However I see the namespaced attributes to be parameters relevent to a particular task. So you would set up the Facility somehow and then install it. Each task however could pass parameters to facility to be handled. (ie log:level="verbose"). >What I am suggested is that context represents this API for >installing/uninstalling aspects. As that they are explicitly supported >in the API. > > I see the logfile attribute being on a LogContext element like: > ><Context id="detailed"> > <LogContext name="current" logfile="log.txt" /> ></Context> > >and I think you see it as a namespace delimited attribute (right?) on >the task itself: > ><Copy log:file="log.txt" /> Not really - I would see file="log.txt" a configuration of the Facility rather than a task specific parameter. > >I prefer the former approach because (IMO) it makes easier to >install/uninstall whole approaches for running tasks: > ><Project context="detailed" ... /> ><Copy context="ignoreMost" ... /> > >Now that I have looked at a possible API for what I suggest, I do >agree that it may not really be simpler for the user since the basic >user will not even be aware that namespaces are being used. However, I >do think the flexibility for installing/uninstalling whole contexts is >key and I am not sure how you propose to handle that from an XML api >perspective. If I understand you correctly you are proposing a generalized version of recorder task that can configure any facility rather than just logging? If so then I like that idea and I think namespaces are othogonal to it (assuming we make a clear distinction between task-specific parameters and global Facility parameters). I had assumed we would continue to use the command line for these things but I guess your approach is much better. Cheers, Pete *-----------------------------------------------------* | "Faced with the choice between changing one's mind, | | and proving that there is no need to do so - almost | | everyone gets busy on the proof." | | - John Kenneth Galbraith | *-----------------------------------------------------*
