On Saturday 29 March 2003 03:11 am, Tim Jansen wrote:  
> > > desktop. We need a way to let NX server "publish" its applications  
> >  
> > Is this a possible usage for an SLP server?  
>  
> Yes, but the problem is that the existing SLP servers usually still need  
> some daemon that creates the SLP registration and keeps it open. NX does  
> not have a daemon itself, but uses sshd and starts the proxy on demand.  
  
nxserver can keep open the connection with nxclient and interact in  
the same way as a FTP client can interact with server. This interface  
is very "scriptable" and this was one of the design goals (think at  
HTTP integration). This feature is not used at the moment as, once  
the nxproxy is started, it is able to handle the minimal interaction with  
the user by itself (if you look at sshlog in .nx directory you'll find that  
the last command is an "exit"). Actually this is not a bad idea, as  
nxclient can reconnect, if needed, and issue new commands affecting  
an existing session. This saves a lot of resources on -really- thin  
clients, like embedded versions of Linux (iPAQ, Zaurus) or the  
PlayStation2.  
  
I don't think you should look at that layer. Once a proxy tunnel has  
been established between client and server, the application server   
side proxy acts as a X display, tunneling X protocol to the real X  
server. I think KDE/krdc should communicate at X level, using  
properties and selections and X inter-client communication protocol.  
I thought DCOP was able to use X as IPC transport. I read some  
K-documents about this in the past, but maybe I'm wrong. Sorry, but  
I was so involved in this X stuff, lately, that I didn't follow the latest  
GNOME and KDE trends :-/. IMHO, this makes very simple to   
integrate different desktop environments and even enable low-level  
device drivers to communicate with higher level X software.  
  
We think that the next challenge is to make X a pervasive computing  
environment. Think at a washing machine that is able to show its  
interface on your portable, foldable, pocket display. I think that such  
a small application should be able to interact with existing desktop  
elements without using any other communication mean than X  
protocol and a XACP (X Application Communication and Publishing  
Protocol :-) extension.  
  
nxproxy can transport an arbitrary number of "channels" to handle  
any kind of client-server communication (it already transports SMB,  
multimedia, embedded keyboard on iPAQ and Zaurus and rsync  
protocol). It's trivial to add a new channel to handle SOAP/XML-RPC  
or HTTP, but we should carefully think if this is a good idea. Channels  
are intended to let not-X-aware applications to communicate. They  
are even a potential security threat.  
  
> As sshd has no idea about NX,  
  
Of course sshd must not have any idea of NX, the way Apache  
doesn't need to know what your PHP application is doing. SSH is used  
the way HTTPD is used by web applications, infact, at the beginning  
we were using Apache, but it didn't offer a good infrastructure to let  
processes run as real users. The same applies to X. I think the fact  
you don't  have to open the door to new potentially flawed network  
services, other than those you are already keeping open, comes as  
a bonus.  
  
> it can not announce the SLP service.   
  
It's not sshd but it's nxserver that runs in background and monitors  
your session. It can announce any service to any nxclient that's  
keeping the connection open or any KDE component that's able to  
interact through the X server.  
  
I talked on XFree86 forum about some suggestions on how to handle  
IPC between X clients efficiently. Everybody agree that the problem  
is not X but the way Xlib and clients deal with protocol's replies.  
  
/Gian Filippo Pinzari.  
  
 
>> Visit http://mail.kde.org/mailman/listinfo/kde-devel#unsub to unsubscribe <<