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

List:       kfm-devel
Subject:    Re: URLs
From:       weis () stud ! uni-frankfurt ! de
Date:       1997-07-13 0:36:52
[Download RAW message or body]

Hi,

A rewrite of KURL is needed anyway. Stefan ( the other one )
wants to write a new IO Subsystem that can handle tars on ftp
for example and stuff like that. While doing this we can
try to do the encode/decode stuff as mentioned below.

Since encode/decode moves into KURL, every app should work
find then.

But some problems are hard to solve. For example

file:/root may be a URL or it may be a directory file: in the
current directory. This is not decideable => We assume a URL.
If someone has such stupid filenames, he wants trouble.

Bye
Torben


On Sat, 12 Jul 1997, Stephan Kulow wrote:

> Hi guys!
> 
> While fiddeling with files with '#', I found a little problem
> with the definition of an URL:
> 
> I've created a directory called "http:" with a subdirectory
> "www.test.de" and a file with in called "test#section?%23" and
> I made some tests, what application handles this right.
> - vi has no problems with it :-)
> - if I "open file" within netscape, it says "can't open test",
>  that means, it has the same problems like kedit (below)
> - if I open file:/home/coolo/http:/www.test.de/, it opens the file
>  as: test%23section%3F%2523, that means he escapes the unsave chars.
>  (this is RFC1783 conform!)
> - if I run `kedit http://...` or even, if I run `kedit ./http://...`,
>  kedit thinks, it's a URL, unless I call it with /home/coolo/http:...,
>  but then kedit has problems with the # in the name.
>  Only to clearify: this behaviour is correct related to RFC 1783, 
>  since the # is NOT part of the URL, but the problem is, I haven't
>  entered a URL, but a filename! (kedit is of course a place holder 
>  for almost every app, that uses kurl and libkfm)
> - kfm shows this directories and the file correct (with my patch),
>  but I can't open or drag this files with the URL meaning.
> 
> Torben, you said, you would change the way, filenames are handled,
> to make sure, they're not misinterpreted, but I think, the problem
> is a little deeper. Because then you have the same problem with 
> calling kedit as I had. I would suggest to encode the filenames like
> described in the RFC, but they have to be displayed undecoded. I don't
> understand the KFM code that much, as I would volunteer here ;-), but
> I would suggest to add a flag to kurl, that allows automatic encoding
> and a method within kurl, that allows automatic decoding URLs.
> AFAIK kedit looks at his argument and if kedit founds ":/" within
> the argument, he thinks it's an URL and let kfm open this file.
> I can't stop this only with a starting /. Of course my case is almost
> unnatural, nobody will have a director called http:, but he could 
> have one, that has a ':' as the last character of a directory name.
> 
> I think, a test, if the argument starts with a supported protocoll,
> is better, but this shouldn't coded by every app, it should be better
> done within kurl (or a new class, since not every app supports every
> protocoll). If the app thinks, it is a URL, he should call kurl with-
> out encoding, but if this isn't a URL, it is a must to encode the
> argument. And if the app (or kfm) wants to handle the file ment by
> the URL, it must be decoded. I can program the needed code from kurl,
> but this has no sense without this is used first within kfm and second
> in the apps. 
> 
> Finally, I think, the '#' is a bad (known) bug within the whole net
> system of the KDE, so we should fix it ASAP. But I understand, if this
> isn't the top of Torben's TODO list, since it maybe some seldom cases,
> in which this makes trouble, but AFAIK emacs stores temporary files
> as #file# and you can't open this one with dragging it from kfm to
> kedit (for example).
> 
> Greets, Stephan
> 
> 

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