From: "Stefan Bodewig" <[EMAIL PROTECTED]> > On Mon, 22 Oct 2001, Peter Donald <[EMAIL PROTECTED]> wrote: > > > On Mon, 22 Oct 2001 17:42, Stefan Bodewig wrote: > > Fine grain services allow tasks to do more interesting stuff but > > also could be a maintanence nightmare and overly constraining as we > > evolve. Large interfaces can be inflexible. > > Let's examine what the container needs to provide from our current > knowledge and not stretch that too far. Combined with a note that the > API for "privileged" tasks could be changed even in minor releases, > this should work. >
This is what I was suggesting on some previous message. We can provide several levels of APIs to control the container (OK maybe just 2:-) ). But what I whink we should have is some well defined API that provides well defined services. At this point I can only think or registration kind of services with the container managing visibility rules and such, as I mentioned in another e-mail. But maybe there are others things to look into. > Back to the original subject - would we allow such "privileged" tasks > to live at the same level as targets and how would we identify them? > I do not think we should tie location of tasks with priviledge. For example <property> does not need more priviledges than <available>, they both just set the value of properties. However we like one at project level and the other not. Let me put it this way, the "priviledge" of being allowed at project-level is a different one from the priviledge of being allow extra container access. :-) Jose Alberto
