ObjectWeb Consortium
Search ObjectWeb Mail Archive: 

Advanced Search - Powered by Google

Mail Archive Home | deployment List | May 2004 Index

<--  Date Index  --> <--  Thread Index  -->

Re: [fractal] Re: [architecture] Fractal packaging & deployment, bis

El mar, 11-05-2004 a las 09:29, Eric Bruneton escribió:
> Richard S. Hall wrote:
> > This really depends on whether the purpose is to create a
> > deployment infrastructure for deploying Fractal-based applications
> > or if the purpose is to create a more general deployment middleware
> > (at least for Java), where Fractal-based applications are just one
> > type of application to be deployed.
> >
> > If the purpose is only for Fractal-based applications and the only
> > types of dependencies that exist among "packages" are
> > component-oriented dependencies (i.e., containment and binding),
> > then it probably doesn't make a difference what you call it.
> I hope it will be possible to create a deployment infrastructure for 
> deploying Fractal-based applications that can also deploy arbitrary 
> (Java and non Java) applications. This is not contradictory: it just 
> imply that arbitrary applications can be seen as Fractal-based 
> applications (and this should be possible since the Fractal model is 
> modular, extensible, and not tied to Java; for example, plain old 
> Java objects are compliant with Fractal level 0). Or, in other terms, 
> that existing packaging formats can be seen as Fractal packages (and, 
> in particular, that their dependencies can be seen as Fractal 
> "containment and binding" dependencies - hence this mail 
> http://www.objectweb.org/wws/arc/fractal/2004-05/msg00005.html). Or, 

Ummmm, are you sure that "contaiment and binding" dependencies are
expresive enough to represent all kinds of dependencies for existing
packaging formats?

For example, in Debian, package metadata explicitly consider conflicts
between packages. How can contaiment and binding dependencies be used to
describe conflicts between packages? 

Sometimes due to any reason two existing packages can not live
together(for example, both packages access a resource that can not be
shared), in other words, are incompatible. I feel that conflict
management is an important aspect in order to keep the consistency and
the stability of an execution environment. 


<--  Date Index  --> <--  Thread Index  -->

Reply via email to:

Powered by MHonArc.

Copyright © 1999-2005, ObjectWeb Consortium | contact | webmaster.