On Mon, 22 Oct 2001 20:56, Jose Alberto Fernandez wrote: > From: "Peter Donald" <[EMAIL PROTECTED]> > > > On Mon, 22 Oct 2001 17:42, Stefan Bodewig wrote: > > > Declaring TaskContexts (whatever that will be), declaring and > > > attaching build listeners from within a build file, configuring > > > aspects (do we fail on error and all that, this probably is the > > > taskcontext stuff). > > > > those examples work. For these things to be implemented as tasks we are > > definetly going to need the "privlidged" tasks I have talked about in > > past where the container provides specialized services that allows them > > to do all manipulation stuff. > > I do not have a problem with the concept of priviledge tasks. However, I do > not think we should assume we can identify all of them today, nor that such > privileged tasks should be confined to CORE code, by using some secret API > or some other hidden means.
It is not hidden ir secret it is just completely and utterly unsupported and highly likely to change overtime. Think of ants container as a kernel and supporting infrastructure (ie runtime loader/linker/etc). It's interfaces change overtime but the majority of code only depends on the standard c library and thus is never broken or can easily change between different OSes. Anyone who chooses to use these interfaces does so at their own risk and no support should be given to them when it changes. > That is what java.security.Permisions are for. That means that external > code can be given permission to interact more tighter with the container if > necessary. permissions are not important to us as it is highly unlikely we will ever be in a sandbox environment > One thing that puzzles me on this debate is how much enphasis should be > given to "security of the container" in the sense being discussed above. I > can understand the need for high levels of security if the ANT container > were designed to execute code outside the control of the ANT user (like it > is the case with applets or servlets) but in the case of ANT I do not see > this as an escenario in the forseeable future. We are not aiming for sandbox "security" however we do aim to provide an interface that is future proof. This means that we have to have low coupling. However there are some tasks (control flow, container tasks, some type registrations and anything that interacts with runtime) that can not be implemented in a manner that allows low-coupling. Other users of Ant (say a cron engine or installshield app) may also require other services be accessible to certain tasks that are not low coupling. So we need to have a way to allow tasks to request extra services. These interface these services provide is probably container-specific and highly coupled to runtime. Hence anytaks that use such interfaces will potentailly break as we evolve the runtime. I don't think we will disallow such access but we wont support it except for the tasks in ant-dev CVS. For some functionality we will provide abstract base classes that we will support (I am thinking AbstractContainerTask) but this will be the exception rather than the rule. -- Cheers, Pete -------------------------------------------------- Logic: The art of being wrong with confidence... --------------------------------------------------
