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 <<