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

List:       kde-devel
Subject:    Re: KURL bugs
From:       Waldo Bastian <bastian () ens ! ascom ! ch>
Date:       1999-06-18 7:20:11
[Download RAW message or body]

Dawit Alemayehu wrote:
> 
> On Thu, 17 Jun 1999, Waldo Bastian wrote:
> > We should. I would also like to accept
> 
> > file://some_host_name/path/filename and then map it (based on configuration)
> > to either
> >  smb://some_host_name/path/filename
> > or
> >  nfs://some_host_name/path/filename.
> > or
> >   file://some_host_name/path/filename
> >  (but with "//some_host_name/path/filename" ending up in the path)
> 
> But how does one then determine what should be mapped to what ?  What
> configuration is this going to be based on ? 

This is based on kioslaverc. I added a filed "RemoteFileProtocol". If it
is empty the host name is added to the path in the hope that your OS knows
how to handle "//some_host_name/path/filename". If it contains a protocol
name, the "file" protocol is replaced with this protocol.

> IMHO this is out of scope of the
> KURL class.  I will rather needlessly complicate this class.  If you are may be
> talking about a specialized helper class, then perhaps it is possible.

Well.. it's either a 4 line patch to KURL or we need to add a kio_file which
handles file-URLs which have a remote host set.

Yesterday I committed the 4 line patch to KURL. If you think it is more clear
to handle it in a seperate kio_file, we should do that.

The disadvantage of the current approach is that if you pass an URL like
"file://host/path/file" to KURL it may come back as "smb://host/path/file".

Cheers,
Waldo
-- 
KDE, A New Millenium, A New Desktop                      http://www.kde.org

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