On Tue, 20 Jul 1999, Daniel Naber wrote:

> On Tue, 20 Jul 1999, Simon Hausmann wrote:
> 
> > And: We would not loose any functionality, except that kded's services
> > can't be used via CORBA anymore, but the c++ interface are much better
> 
> What does that mean to the use of CORBA-services that are not running
> local? Sounds like that gets impossible/difficult?
> 
> The last time I asked about this (http://lists.kde.org/?l=kde-devel&m=93112687011888&w=2)
> there wasn´t much response, unfortunately. Still I think that using
> remote services as if they were local services is the main reason to
> use CORBA.

Yes, CORBA over networks is nice, but we don't have to forget the security
aspect! In fact the current issue about different ways of IPC for kded is
not really related to this because kded now uses a unix domain socket for
communication for a while now.

The problem has been discussed very often and there's still no real
solution available, so we decided to switch to unix domain sockets for
IPC, since this is *much* safer than open inet sockets!
If you can provide a good security model for kded then we'll implement it
for sure.

And besides you don't have to forget that kded is not only a CORBA thing.
In fact the most often used service is the trader, and this has indeed
nothing (or nearly nothing :) to do with CORBA services. It does not
make sense, IMHO, to make KTrader accept non-local services. I believe
that's quite obvious.

However the situation is different with KActivator, but then we're back
with the security issue.

Just to repeat: If you can provide a good security model then please
*tell* us! Until then we consider it to be better to go the safe way.


Greetings,
 Simon