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

List:       kfm-devel
Subject:    Re: konqueror - multiple instances
From:       Simon Hausmann <tronical () gmx ! net>
Date:       1999-07-18 15:54:55
[Download RAW message or body]

On Sun, 18 Jul 1999, Cristian Tibirna wrote:

> On Sun, 18 Jul 1999, Simon Hausmann wrote:
> 
> > Hi,
> > 
> > Currently we try to keep Konqueror a mostly shared thing, meaning we try
> > to keep only one process running and re-use it as often as possible.
> > 
> > ...this reminds me of kfm...
> > 
> > And this is the point why I'm not very happy with this, at least not in
> > conjunction with the current state of Konqueror.
> > 
> > It *is* possible that Konqueror crashes. See the qxembed trouble as
> > example. Or a bug in an embedded third-party view might crash it.
> > 
> > Currently a crash affects the whole system
> > - all konqueror windows disappear
> > - kfmclient can't connect to konqueror anymore if konqy wasn't able to
> >   unregister properly (from kded) -> even more trouble -> user needs to
> >   restart kded -> requires *all* apps which depend on kded to be restarted
> >   (for example kpanel)
> > - CORBA clients crash, because the process died
> > 
> > Bah, this is not really nice, isn't it? ;-)
> 
> This is so much worse than kde-1.x :-(
> 
> Can't kded be made to check validity of registering once a few seconds (in
> the end, how many corba-dized programs one runs at a time? this shouldn't
> be too penalizing)

The problem is: We are using the naming service for persistent services,
like Konqueror is kind of.

When using KActivator and the IMR/Mediators, then this problem doesn't
exist since the mediators take care of restarting a crashed server (that's
the advantage over the GNOMEish way of using a naming service all over
the place, I think)

And I think performing invokations on all registered objects at KNaming in
a certain time-frame is not really the job of a naming service.

So it's not really kded's fault but the way we use it.

The reason why Konqueror uses the naming service was that when konqueror
was not started by the mediators it will register itself at KNaming, so
that kfmclient can still find it.

So IMHO the only solution is to get rid of the fact that
Konqueror registers at the naming service. Indeed I did some real bullshit
when I implemented this functionality, since I should have known that
Konqueror is not (yet?) really a persistent/stable process.

Only really persistent and stable processes should register objects at
KNaming, like KDesky!

> > So why not minimize the sharing mechanism a little bit?
> > 
> > We could keep *one* instance available for KActivator (no more KNaming
> > support) and we simply make kfmclient execute a new Konqueror process.
> 
> I personally would very much prefer to be able to stop konqueror at all
> (it will undisputably be the largest resource consumer in kde-2) when I
> really don't use it.

This is feature will still exist when going the way I described :-)

KActivator will only fire up Konqueror on demand only. Same for kfmclient.

> I have a pro-argument for one unique konqueror instance: db-like resource
> sharing: history lists, recent-location lists, bookmarks lists ...

We should then consider moving these resources into a stable server.

I fear that the idea of a 100% stable Konqueror process will remain a
dream, at least for a while :-)

> In fact, I think we have to give a very strong attention to the amount of
> useless application run-process replications in KDE. Some of the authors
> took care of this by themselves (kmail, kikbd...) but IMHO 80% of
> applications should be aware of their own running instances. Konqueror is
> one of these apps. Of course, as long as I don't code for it, I don't have
> much right to criticize things about it, but I believe one-instance per
> user-session is so much better.

Criticism is very much appreciated IMO :-)

In fact I would like to thank you very much for your arguments, because
they brought up the idea of finding a better way of sharing resources
between unstable processes.

> > Opinions? David, Torben?
> 
> (Yeah, I know I'm not D or T :-) I believe the right way to do it is to
> wrap the whole thing in an error handler which will deal with that
> dezastruous kded dead-end leftover or make kded smarter WRT crashing
> programs.

I disagree, because I believe it's not kded's fault.

But: I'm veryveryvery glad that you stated your opinion. So forget my
other mail in which I stated that I'm going to commit the changes.
I'll first try to convince everyone, including *you* :-)

Bye,
 Simon

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