ant-dev mailing list archives

Site index · List index
Message view « Date » · « Thread »
Top « Date » · « Thread »
From Peter Donald <dona...@apache.org>
Subject Re: [Ant2] Tasks as siblings of <target>
Date Tue, 23 Oct 2001 08:54:34 GMT
On Mon, 22 Oct 2001 20:56, Jose Alberto Fernandez wrote:
> From: "Peter Donald" <donaldp@apache.org>
>
> > 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...
--------------------------------------------------

Mime
View raw message