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

List:       kde-devel
Subject:    Re: dcop questions
From:       Rik Hemsley <rik () kde ! org>
Date:       2001-09-10 19:52:56
[Download RAW message or body]

#if Caleb Tennis
> I have done some research into the setServerAddress method but I cannot
> successfully attach to the server.  Based on the address I give it, I
> generally get messages such as "transport method not supported" or
> "authentication errors".  These seem to come from the underlying X code that
> dcop is written on.

DCOP doesn't use X - it uses code _from_ the X distribution.
DCOP runs over UNIX sockets, not TCP, so you won't be able
to use it over a network in the usual manner.

> My question: has anyone done anything like this.  Security isn't much of a
> concern - I just need to know the best setup and configuration for handling
> this information.

Yes, you can use kxmlrpcd. See the docs and examples in the
kdebase/kxmlrpc directory.

On a related note, I'm currently finishing off a DCOP<->SOAP bridge.

A few days ago I did this:

* Started two of my DCOP<->SOAP bridges, running on different ports.

* Wrapped one DCOP message (kicker->restart()) inside another and
  sent that to server #1.

* Server #1 converted the DCOP message to SOAP and sent it via a TCP
  socket to server #2.

* Server #2 converted the SOAP back to a DCOP call and sent that
  to kicker. It then converted the DCOP reply data to SOAP and
  passed it back over the socket.

* Server #1 converted the SOAP reply back into a DCOP message
  and returned it to the sending application.

This is not exactly magical. The tricky bit has been ensuring
the HTTP server part is hack- and DoS-proof.

When I am done with the SOAP/DCOP library and the bridging server, I
intend to provide some more methods in the DCOPClient API, so that
you can call remote objects easily.

The security model is currently exactly the same as the kxmlrpcd model.
It seems OK to me. If you want better security, you'll have to use a ssh
tunnel or perhaps we could do SSL.

Rik

 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<

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