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

List:       kde-devel
Subject:    Re: KURL bugs: defending RFC 1738
From:       Cristian Tibirna <ctibirna () total ! net>
Date:       1999-06-18 15:21:21
[Download RAW message or body]

On Fri, 18 Jun 1999, Oleg Noskov wrote:

> Oh well... I didn't expect to get such an opposition to my bug report.
> All right, if you're trying to be difficult, I'm fully prepared to defend my
> position.

??? Oposition? Ming, do you understand now why it's so important to
discuss things? Even the "art" of discussing needs some training.

Oleg, I doubt somebody is trying to be difficult. AAMOF, Waldo even added
changes to KURL already, starting from your design analysis.

Oh, well, let's pass over and get to work. I personally am very glad to
finally have you all here.

> OK, I suggest you to follow this hyperlink and read it again:
> http://gatsby.tafe.tas.edu.au/CIE/RFC/1738/30.htm
> 
> UNC names are part of life. You cannot simply declare it to be Microsoft
> bullshit.

Part of life yes, part of standards no. Not sticking to standards can be
the biggest threat to what we try to accomplish here.

UNC's became largely used maximum 5 years ago. They can go into obliviance
in another 5-7 years. Let's treat them as special cases, but not blow all
up because of them. KURL is a functional class, more of an interface
between what applications can do with URLs and what happens when they
really do things to them. We must be carefull to how much complexity this
class involves.

> URLs are widely used in communications. There's no such things as
> "Windows-specific" URLs and "UNIX-specific" URLs. All URLs are meant to be used
> across platforms.

UNC's aren't URLs.

> UNC files have dual nature. They have a hostname inside, so the form
> file://machinename/sharename/foldername/.../filename is perfectly legal.
> On the other hand, they can be just like normal local files, and many
> applications prefer to consider them to belong to the local host. Hence,
> file://localhost/\\machinename\sharename\foldername..\filename
> file://localhost///machinename/sharename/foldername../filename
> are OK, too.

Understood. Now, how do you propose to treat the fact that those
backslash names are valid UNIX filenames?

> If you allow non-standard URLs like "file:localFile", the situation gets
> ambiguous.

Maybe you have a point here. I believe this scheme is included for
convenience. I doubt you'll find such URL embeded into a document. But the
filemanager can make heavy use of it by applying completion mechanisms.

Thanks for being here.

Cristian

--
Cristian Tibirna     : ctibirna@total.net     : www.total.net/~ctibirna
PhD Student          : ctibirna@gch.ulaval.ca : web.gch.ulaval.ca/~ctibirna
KDE contact - Canada :  tibirna@kde.org       : www.kde.org

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