[prev in list] [next in list] [prev in thread] [next in thread] 

List:       kde-core-devel
Subject:    Re: dcop interfaces, standard ?
From:       Torben Weis <weis () stud ! uni-frankfurt ! de>
Date:       1999-12-08 22:31:43
[Download RAW message or body]

Hi,

On Mit, 08 Dez 1999, Bernd Gehrmann wrote:
> On Wed, 8 Dec 1999, Simon Hausmann wrote:
> > 
> > > On Wed, 8 Dec 1999, Simon Hausmann wrote:
> > > > > > > And btw (and offtopic), even for embedding I don't see why this should
> > > > > > > necessarily be restricted to shared libraries. It should be possible
> > > > > > > to write a proxy KPart which communicates with another application via
> > > > > > > DCOP and embeds its window via the QXEmbed protocol.
> > > > > > 
> > > > > > It's not only about embedding an X11 window, that's no deal, yeah. The
> > > > > > point about using shared libraries is that you can use the Qt action
> > > > > > pattern.
> > > > > 
> > > > > Then this further rules out KParts for me. And furthermore, it
> > > > > would be real license mess. I'm not going to put my programs
> > > > > under the GPL just because some freaks use such viral licenses.
> > > > 
> > > > Sorry, but I don't get your point. (please help :)
> > > > 
> > > > What's wrong with using shared libraries, also in regard to the
> > > > (excellent) Qt action pattern? 
> > > 
> > > It's a step back to the old days of DOS. Unix provides the
> > > ability to protect processes from each other, and every
> > > reasonable person makes use of this. Windows programmers
> > > have waited long for this feature, and its lack of memory
> > > protection is the greatest weakness of MacOS.
> > 
> > Protecting processes from each other doesn't help to solve the problem of
> > embedding.
> 
> Talking to an application to open a file is not embedding.
> 
> > Just in contrary. As the old KOffice showed: Separating
> > components in processes, for embedding, is less stable.
> > (and DCOP wouldn't help here, as it's a general problem of distributed
> > environments IMHO)
> 
> ??? From what I remember what Torben said, the embedding
> code was full of bugs. How can you take buggy code as an
> argument against separate processes???
> 
> I use coprocesses all the time and in several programs
> and it works very well and is ultra-stable. I have no
> idea how you can say that there is a stability problem.

In practice it often shows that dealing wirth multiple processes in a
distributed object environment you get really big problems because
it is so easy to make errors.

In the end it does not help if you end up with a system that is theoretically
rock solid but practically buggy because the technology used was too difficult
to deal with.

The user only counts the amount of crashes per year. And if you get almost none
with an inherently unprefect solution that is better than having many of them
in a system that could be stable.

And all the CORBA stuff we used was not good for fault tolerance. Nobody
caught all kind of exceptions in every single CORBA call. So a dying component
killed all the other ones on a short time usually.

That is IMHO the difference between theory and practice :-)

Of course a system with multiple processes can be implemented reliably
if the communication and dependencies between them are not too complex.
But for KOffice they were REALLY complex.

Bye
Torben
 
> Bernd.

[prev in list] [next in list] [prev in thread] [next in thread]