[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Re: NX Project Announcement
From: pinzari () medialogic ! it
Date: 2003-03-29 17:10:28
[Download RAW message or body]
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 <<
[prev in list] [next in list] [prev in thread] [next in thread]
Configure |
About |
News |
Add a list |
Sponsored by KoreLogic