[EROS-Arch] Package handling...

Pascal J. Bourguignon pjb@imaginet.fr
Wed, 28 Mar 2001 16:40:33 +0200 (CEST)


> From: "Jonathan S. Shapiro" <shap@cs.jhu.edu>
> 
> Joerg Bornschein wrote:
> > 
> > There may be solutions to these other problems that I am unaware of.
> > 
> > I think the most important unsolved(?) problem is that constructors don't
> > know whether there are instances running or not....
> 
> There is a large, dangerous snark here.
> 
> Forget about the security implications for a moment. Consider first the
> implications of warranty.
> 
> If I build a program that relies on a component, I have tested my
> program against a particular version of that component. The updated
> component may be better, but it may or may not have been tested under
> the same assumptions as my program, and it may or may not *work* in my
> program. Therefore, the component must not be updated in the context of
> my program until my program agrees to the update.
> 
> This means that update must be performed on a "pull" rather than a
> "push" model. My application must somehow be notified that an update is
> available, and must then decide whether to accept it or not.
> 
> Update is an option that wants to remain open. You may ship an update.
> The application vendor may later test it and say "okay, that update is
> okay for my app". The app vendor may then ship an app patch that says
> the update is okay, after which the app may consent to the update.
> 
> However, forcible update is not the right thing.

I don't  know. I see  a little this  installation phase as  setting up
links between collections of  objects. Therefore, it should not import
too much to a certain object A  to be connected to some other object X
or  Y,  _as_long_as_  these  objects  implements  the  same  interface
specified for the object A.

If an  applications wants to  be installed with  a capacity to  read a
file, I think the administrator and/or the user should be free to give
it a capacity to read a local device, a remote file or device, or from
a "pipe"  or whatever, as long as  the interface is the  same (and the
syntax of  the data read matches).  (Of course the  definition of such
interfaces should  include pre & post  conditition so it's  not only a
syntax, but also some semantic that is specified).

Now, if the  vendor does not provide a  guarantee that its application
will  work with  another  object than  X,  v. 1.0,  let  him state  it
clearly,  but  let the  user  choose how  he  wants  to integrate  the
application in his system. Or not?


-- 
__Pascal_Bourguignon__              (o_ Software patents are endangering
()  ASCII ribbon against html email //\ the computer industry all around
/\  and Microsoft attachments.      V_/ the world http://lpf.ai.mit.edu/
1962:DO20I=1.100  2001:my($f)=`fortune`;  http://petition.eurolinux.org/