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

List:       kde-devel
Subject:    Re: thoughts about network integration in KDE2, please read (was:
From:       Nicolas Brodu <brodun () aston ! ac ! uk>
Date:       1999-12-02 11:24:29
[Download RAW message or body]

aleXXX wrote:
> 
> As I was thinking about Samba and NFS-support for KDE 2, a LAN-ioslave, which
> transparently supports both and how to use the stuff from my kNetmon I was a
> little bit confused. In my app I store the information about workgroups, hosts,
> shares  and so on in a tree-like structure. Somehow I could not figure out,
> how to transform this into an ioslave correctly/logically. OTOH I was really
> sure that it can't be wrong to use internally a data-structure which
> fits the entities and their relationship in reality.
> Then I found it ! :)

Hi Alex!
Glad we finally move this debate on kde-devel.

> We want to have transparent network access in KDE, so we have to do it !
> In this case the KleinWeich explorer is not so bad with its tree structure for
> the LAN, I think you know what I mean. Wouldn't it be even *much* better to
> have something like this in konqy and every kde-file-dialog:
 
[snip Alex descriptive tree]
 
> You could enter network://ftp.troll.no/FTP,  and you would access this host
> by ftp, you could enter network://host1/samba/mp3 to access this directory.
> (we could avoide the groupname by looking up the host name in all groups).


For completeness, I'll post my point of view :-)

Here is how I see it (Alex, I'll answer to your last private mail when I have
studied your code a bit, please be patient...):

That's currently how this is done in the IOSlaves:

class SmbProtocol : public KIOProtocol
 
If you now declare

class LanProtocol : public KIOProtocol

and implement all the common stuff about shares, hosts,... in this class.
You can inherit:

class SmbProtocol : public LanProtocol
class NfsProtocol : public LanProtocol

And you have the advantages about inheritance, virtual functions,... for code
reuse.
Moreover, it fits perfectly with the kio scheme, since it would be possible to
make a common kio_lan that contains the rules for merging protocols.
You can still call kio_smb or kio_nfs if you want to use a specific protocol,
and later on you can add 

class WhateverProtocol : public LanProtocol

and the corresponding merging rule for other stuff if necessary.
(for example, CODA, IPX/SPX, DECNET, swpackage on HP systems,...)

(Precision, I'm talking about merging the lan protocols in a lan ioslave, NOT
in the LanProtocol class that doesn't know about its derivates)

Alex sees it the other way around, where you delare a class for each type
of node and a global class Node that derivates from all these.
But by the aid of virtual functions, both approaches are equivalent.

> Wouldn't it be almost the greatest at all if we could have autocompletion for
> this ?
> To the author of konsole: Would it be possible for Konsole to catch the tab-key
> to do its own autocompletion ?
> Then it might perhaps be possible to have autocompletion for
> hostnames and shares in bash !

Hey, great idea!
Even with the current scheme for IOSlaves, it would be a great thing that
the user can press, for ex, 'wget http://www.kd<tab>' :-)
Of course, tab still needs to be passed to the shell for usual 
auto-completion.

[snip] 
> ...waiting for comments

Hmmm, this whole 'local computer / network' thing was what I disliked most
about windows explorer when I had to use it. And it's not transparency
anymore, to my mind, since we precisely make the distinction. I think
the url approach is great, as it Uniform(ize?) the Ressources Locations,
and that's what we want.
I like the way you merged the protocols in Knetmon/knife, with all possible
shares using different protocols on one machine. That's why I proposed
this lan ioslave above: if 'file' doesn't find the file locally, it can
just call lan to check if there is something out there. All the merging stuff
is moved out of 'file' into 'lan'.
Now, I'd also like to have the explicit protocols, because if a user types
'nfs://this_host/this_share' he/she obviously know what she/he wants,
and there is no need for scanning the host using other protocols.

Cheers,
Nicolas

-- 
Life is a sexually transmitted fatal disease. (W. Allen?)

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