[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: Samba and NFS support)
From:       Dawit Alemayehu <adawit () earthlink ! net>
Date:       1999-12-02 21:25:12
[Download RAW message or body]

On Thu, 02 Dec 1999, 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 ! :)
> 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:
> 
> +-local_host   //this part exists
> |   |
> |   +-bin/
> |   |
> |   +-etc/
> |   |
> |   +-usr
> |       |
> |       +-bin/
> |       |
> |       +-doc/
> |
> +-network   //this part is new
>     |
>     +-workgroup1
>     |    |
>     |    +-host1
>     |    |    |
>     |    |    +-Ports/
>     |    |    |
>     |    |    +-WWW/
>     |    |    |
>     |    |    +-FTP
>     |    |    |   |
>     |    |    |   +-bin/
>     |    |    |   |
>     |    |    |   +-pub/
>     |    |    |
>     |    |    +-NFS
>     |    |    |   |
>     |    |    |   +-public/
>     |    |    |   |
>     |    |    |   +-home/
>     |    |    |
>     |    |    +-Samba
>     |    |        |
>     |    |        +-pics/
>     |    |        |
>     |    |        +-mp3s/
>     |    |        |
>     |    |        +-other_stuff/
>     |    |
>     |    +-another_host/
>     |    |
>     |    +-yet_another_host/
>     |
>     +-another_group_of_hosts
>          |
>          +-http.microsoft.somewhere
>          |   |
>          |   +-Ports/
>          |   |
>          |   +-WWW/
>          |   |
>          |   +-Samba/
>          |
>          +-ftp.troll.no
>              |
>              +-Ports/
>              |
>              +-FTP/
>              
> 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).
> Wouldn't it be almost the greatest at all if we could have autocompletion for
> this ?

There will be an autocompletion class for this exact case, i.e. performs
autcompletion of remote directories/files after KRASH.  Carsten has already
written two classes, KCompletion and KURLCompletion which inherits from it. 
KURLCompletion performs exactly what you are saying here (at least I think do).
I have modified KLineEdit and added a KComboBox class to make use of these
feature.  Anyways, all of these will be added after KRASH upon consensus.

> To the author of konsole: Would it be possible for Konsole to catch the tab-key
> to do its own autocompletion ? 

It does this only for local resources just like a normal shell.  But I think
with the addition of the autocompletion classes, I guess people can be
encouraged to provide such capabilities.

> Then it might perhaps be possible to have autocompletion for
> hostnames and shares in bash !
Right.

> To do this whole stuff we need an ioslave/server which must be configured to
> show certain groups of hosts (did you notice I  didn't use the term workgroup
> ?), which is then able to scan the  groups for hosts (using samba or
> lowlevel-tcp-ping), which is able  to detect wether a host supports
> samba/nfs/ftp/http and which  stores this information.
> This is what my app already can do (and more).
> Then if you want e.g. network://www.microsoft.nl/WWW this server  would have
> to redirect it to http://www.microsoft.nl (not hard to do, you can use directly
> the WWW/FTP/Samba/NFS/Port/whatever part of the URL).
> This server would/could store/cache the information about the
> hosts/shares/FTP-dirs/html-pages to make a fast access to this information e.g.
> for autocompletion possible. The server would also make it possible to mount
> e.g. NFS-directories transparently (the first time you access it it is mounted,
> unmounted if you tell it to, or if KDE quits, or after 1 hour or...)..

To me what you are proposing is much the same as PURL (Persistent URL's) or
IKW ( internet keyworks which there is already support for in konqy thanks to
Yves ) except it must done locally.  Let me explain.  I will use IKW as an
example.  IKW works by intercepting what a user types in the location bar if
and when it is not a valid URL and prepending a fully qualified valid address
of a keyword resolution host.  This URI is then sent to KIOJob which will
attempt to fetch it without a problem.  The server then finds a match and uses a
HTTP redirection to send you to the correct location.  If no match is found, you
will then be forwarded to a search engine or given an error message based on
your preference.  PURL would work much the same way.

So  in order to make your idea work, you can do either of the following :

1.) Intercept all URIs that are entered in the location bar and check for
your keyword network://.  If found, parse the URI and put it in the "proper"
format.  After that you can simply send it to KIOJob and it will not complain.

2.) Create your own io-slave (well actually a filtering io-slave) for
network://.  All this io-slave would do is what number one does and then cause
a redirection signal with the appropriate URI.  IMHO this is an over kill.  I
think #1 is your best bet.

BTW, you need to do the above because KIO is very much dependent on
the protocol of a URI.  It uses this information to obtain the fully qualified
location of the appropriate io-slave using KProtocolManager.

Regards,
Dawit A.

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