[prev in list] [next in list] [prev in thread] [next in thread]
List: kde-devel
Subject: Re: knot protocols
From: Tim Jansen <ml () tjansen ! de>
Date: 2003-07-03 17:50:07
[Download RAW message or body]
On Thursday 03 July 2003 11:41, Brad Hards wrote:
> By the looks of the documentation, you tried to keep the "native" interface
> (kdeapi?) at least mostly independent of SLP - only a couple of SLPism in
> there (eg KDE::SLP::Registry::findScopes).
That was not my focus. IMHO API abstractions like Java's JNDI and Apple's NSLM
are confusing. In order to understand them you need to map their abstract
names (e.g. Neighboorhood in NSL) to the implementation (scopes in SLP,
domain names in DNS-SD). Limitations and special rules of implementations are
not obvious, for instance DNS-SD has no multi-language support, even if the
API would support it because of SLP.
Basically the only thing that DNS-SD and SLP have in common is that services
have a set of attributes. And even there DNS-SD has limitations that would
make the API more complicated (all attribute including their names should fit
into 400 bytes, hard limit of ~1300 bytes, restricted charset for attribute
names etc) and no support/common syntax for anything but strings and
binaries.
> Is the intent that knot might eventually support other service location /
> discovery protocols? Or is meant to be even wider in usage?
> [...]
> Do you have anything in particular in mind for the implementation?
Knot is intended for additional protocols. On the top of the list is a special
HTTP server that allows applications to offer services via HTTP by giving
them a virtual folder that they can control, or optionally their own HTTP
service on a distinguished port. This could solve several problems. Right now
there are four HTTP implementations in KDE CVS (kpf, krfb, kxmlrpcd and
saape). They all run on separate ports and either don't work with several
simultanous users (thin-clients, fast user switching) or they allocate a new
port for each user. Knot could unify those implementations, stop the port
allocation madness and be used as a secure barrier between the applications
and the network. I also want the HTTP module for showing SLP debug
information. My number one problem with debugging OpenSLP problems is that I
never know which services are registered.
DNS-SD has been a thought, but as I don't know a single Linux app that uses it
and SLP can do everything that DNS-SD can, my interest is limited.
I have some ideas for other things after HTTP. Either I focus on real-time
communications and implement SIP (by adopting libdissipate), or I work on a
Active Directory-like solution for managing users, computers and other
resources with a Kerberos, LDAP and SLP mix.
I don't know yet, the target for version 1.0 is just SLP+HTTP+the filesharing
module+a naming module.
> Say for DNS-SD, would you expect to use a second daemon?
No. If possible the network services should run in the same process to save
resources. But some services/modules may need more privileges, and for them
it is necessary to fork additional processes. e.g. the file sharing module
will need to run as root, but can drop all capabilities except
CAP_DAC_READ_SEARCH. The processes are also used as barriers between the
modules to avoid that a exploit can spread out and gain privileges. Thus the
file sharing module would use the existing IPC mechanism to register SLP
services for the shares.
bye...
>> 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