Hi Bert,

>> there always should be two leading /, after the name of the
>> protocol. So we allow the first two lines above only for convenience.
>
> Right.
>
>> But how could one create a local url (in the case of Squeak
>> local to the current squeak dir, I guess) legally?
>
> You mean a "relative url"? There is no such thing.
Mmmh, but why is there an instance-variable called "isAbsolute" in 
FileUrl?
Should we get rid of that?
>
>> Right now you can't.
>
> Why not? Suppose your base document is 
> 'file:///home/markus/squeak/foo', then a relative reference to access 
> 'file:///home/markus/squeak/bar' would be 'bar'.
>
> "Relative urls" only make sense with respect to some base document. 
> You take the url of the base document, strip anything past the last 
> slash, and append your relative path. A "relative" url is signified by 
> the absence of the scheme part, and possibly the host part and path 
> part.
>
>> So I would suggest, that 'file://foo/bar' asUrl pathForFile
>> should give us a _local_ file, and that
>>  'file://foo/bar' asUrl isAbsolute" should yield false.
>
> Nonsense. 'file://foo/bar' refers to file '/bar' on host 'foo'.
Yes and no.
Certainly you are right, that the first part can stand for the host,
but it also can be empty. And if the rest is a path, what then?

I actually don't know, when you want to give the host here at all,
as file:// is only useful, when you are on your host.
>
> We could define "FileDirectory default" to be the base URL for all 
> Squeak content. You then could access stuff with just 'foo/bar/baz' 
> which would be relative to the Squeak default directory. We'd just 
> have to write this convention down somewhere.
I think we should.
>
> As an extension, we can treat 'file:foo/bar/baz' the same by just 
> stripping the 'file:' part. And we can convert 'file:/foo/bar/baz' 
> into the correct 'file:///foo/bar/baz'. These "convenience" urls seem 
> useful to me. Now this is exactly what Squeak currently does, right? I 
> did not check, but it should.
Right now:
	 'file:///foo/bar/baz' asUrl pathForFile -->  'foo/bar/baz'

pathForFile is used for example in

FileUrl >> retrieveContents
	| file pathString s type entries |
	pathString _ self pathForFile.
	file _ [FileStream readOnlyFileNamed: pathString]
	(...)

and this creates a _local_ file out of that.

But this should be fixed with my [FIX]-Post.

Cheers,

Markus