Markus Gaelli wrote:

> 
> 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?

Don't know. Perhaps it is only an optimization? Or it comes from some 
MacHead who can't get used to URLs? On Mac, 'foo:bar' is absolute ...

>>> 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?

Then you have triple slashes.

> 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.

For example, using SMB you can actually access files on other host in 
your LAN, which is not public access.

>>
>> 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.

I'm not quite sure about this. I tend to think The Right Thing to do 
would be to use only absolute file URLs. This can be handled by 
prepending the current default path when creating the URL object from a 
"relative" string.

>> 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'

That should be '/foo/bar/baz' (assuming you're on Unix).

> 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.

Great! :-)

-- Bert