On Fri, 9 Feb 2001, Dan Harkless wrote:
> Jan Prikryl <[EMAIL PROTECTED]> writes:
> > The colon is a relict of DOS path notation (C:\....) so it cannot
> > appear in a filename.
>
> Fine, but I'm not really up for obfuscating the URLs on UNIX just to make
> DOS/Windows happy. Already the Windows port has to deal with more
> characters being non-allowed in filenames than on UNIX. This is just
> another one.
Clearly, the non-unix ports can be modified to deal with incompatible
filenames. I think this is more a question of whether you
intentionally want to create portability problems when creating new
code. There is no question that portability comes at a price. In this
case it is loss of the exact URL in the new filepath. From a systems
viewpoint, it seems much simpler to avoid problem code rather than
assume that someone can create a workaround for those systems where
it doesn't work. This just adds to the complexity of maintaining the
code. The created path is an indication of the origin of the files,
not necessarily a full URL. As noted in other posts, the protocol name
has not previously been included in the path, so this has never been
the full URL. Perhaps I am too used to DOS and Windows ports of unix
programs, but the mentioned alternatives to the colon in the filename
all looked reasonable and intuitive to me. I didn't perceive any
obfuscation.
Doug
__
Doug Kaufman
Internet: [EMAIL PROTECTED]
