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

List:       kde-devel
Subject:    Re: ktop
From:       Simon Hausmann <tronical () gmx ! net>
Date:       1999-06-23 11:14:00
[Download RAW message or body]

On Wed, 23 Jun 1999, Bernd Gehrmann wrote:

> On Wed, 23 Jun 1999, Simon Hausmann wrote:
> > > On Tue, 22 Jun 1999 Simon Hausmann wrote:
> > > >What about making this performance monitor a CORBA server instead of yet
> > > >another daemon? 
> > > >Advantages:
> > > >1) You don't have to deal with the IPC issue, because CORBA is your friend
> > > >2) It would be accessible for all KDE apps through kded
> > > >3) One could even access it from KScripts! (would need kded support in
> > > >   libkscript -> no problem)
> > > >4) It would be launched on demand only -> save resources
...
> > Well, nevertheless you'd drop all above mentioned advantages with this,
> > and IMHO they're not that bad.
> 
> Why?

Number 1) is obvious I think. (the Connection/Slave classes from
kio_connection.h might help to re-use code though)

I admit that Number 2) is a matter of taste. It depends on whether you let
the client app require to link against idl generated code or a library.

For number 3) it might be more likely that KScript gets kded support
anyway, rather than extra support for the extra lib. (and CORBA support is
builtin already!)
But this also depends on Torben's decisions (as maintainer/author) about
KScript extensions in general. (Perhaps it's possible to make KScript load
a KSModule dynamically, just like with Mosfet's KStyle stuff?)

Number 4) depends on the design of your lib, although I guess that it
might be a re-invention of the wheel, because the mechanism is already
available..

Ciao,
  Simon


--
I bought a cheap virus-killer from Mickeysoft for only $400, now I got rid
of the .signature virus! ;-)

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