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

List:       kde-devel
Subject:    Re: Summary and possible solution for merging protocols
From:       aleXXX <alexander.neundorf () rz ! tu-ilmenau ! de>
Date:       1999-12-03 13:25:05
[Download RAW message or body]

On Fri, 03 Dec 1999, Nicolas Brodu wrote:
> Goal:
> 
> Being able to target an host with a slave and get back all its exported
> ressources, whatever the protocol.
> I join Alex in the opinion that in a LAN environment, you might want to
> check what's on a specific host, independantly of the protocol (nfs, smb, 
> ftp, http,...)
> More, you might want to get a list of all the machines present on your LAN
> so as to be able to browse them later on.
> 
> Problem:
> 
> For a small LAN, you might get a list of all hosts that offer a specific
> service, but how would you know which machines offer, for example, ftp or 
> nfs, without scanning them all? It's not acceptable if your LAN gather 
> several hundred machines.

Why ?
It doesn't take time to scan for hosts.
Here (12 bit host-Id) it takes about 10-15 seconds and gives up to 500 hosts.
A problem: there has to be some good way to configure it.
If we only use net-address/netmask and scan all, it is not always what you want
to.
If there are windows-workgoups then it would be nice to be able to scan a single
workgroup. Maybe one could start scanning using smb, collecting the found
machines and their IP-addresses and if we have all (?) start scanning for them
using IP-addresses.

If you open a host then it will scan for the provided services.

> Possible solution:
> 
> Create a virtual protocol, called 'any', that would merge results from
> different protocols, and can only work when you target a specific host.
> Of course, one might argue that smb:// is relevant, as it can return a list
> of workgroups, but what for ftp://, or nfs://? 
Yes but how to scan for hosts ?
I suggest to configure some groups, and any://group_name returns the hosts,
any://groupname/host as you mentioned.
More than one group, because there can be more than one workgroup, or you don't
have workgroups but a big host-Id and you want to sort them into groups (some
way).
As I mentioned, to provide a nice/easy usable/understandable configuration
dialog for this may be a bit hard.

To make it shorter we could avoid the groupname by searching for the
hostname in all configured groups (which where already searched for hosts).

> So:
> - 'any://this_host/' would return the list of ressources independantly of
> the protocol (still problem here on how to merge html pages with nfs
> shares, but let's assume it returns a list of files & dirs for now).
> Ressources are then acceses with paths as in any other URL. 
> (any://host/path.../a_file)
Yes.
I suggested to provide the different services as different directories of a
host.  One installed protocol on a host = one directory on the host = one
special ioslave. 
The user can handle them all the same way, but he sees what he is doing.

> - 'any://' not valid, unless it is restricted to 'smb://' (except if someone 
> comes up with a solution for other protocols). In this restricted case,
> you can still get a .desktop link to any:// on your desktop if you really
> wish so.
> - You can call 'any' for a non-LAN host as well.
Yes.
Why not.
This is what I wanted to say in my example with the group with ftp.somethign and
www.somewhere.

> - We keep all the existing well-separated kio_slaves in case the user
> knows what she/he wants. 
Yes.

> Note about the merging process:
> Can scan the ports of target host to found supported protocols, and then call
> the corresponding ioslaves. Conflicts can be handled by prefix depending
> on the protocol (see knetmon/netknife) and/or setting up a user prefered
> order.
See my comment about the directories.
Let's say a host has 5 samba shares, 3 NFS exports and perhaps 7
root-ftp-directories.
If we have them all at one level it will become a bit muchand maybe confusing.

Bye
Alex

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