> On 27-12-2017, at 3:36 AM, Jakob Reschke <forums.jakob at resfarm.de> wrote:
> 
> I have not thoroughly investigated this, but this could be a case for the FileSystem API that Pharo has adopted as the default file accessing API. You do not pass file names around there, but references that are (path + the FileSystem in which they resolve). That way, the information that the gif lives remotely is not lost. Each FileSystem is then responsible for file name conversion and encoding if required.

That’s certainly one option and potentially a very good one. I’ve always hated the way that raw strings have ended up as the ‘normal’ way to refer to file locations. It got even worse with UTF-8 getting mixed in. There’s a lot to be said for having fairly use-specific objects to refer to file locations; it might be smart to have platform specific classes not just for the differing separators, length limits and so on, but as a way to help translating between OS as an image is moved around. As a current example, the Turing talk image Yoshiki just mentioned has a link to a movie file at C:\something or other; a way to meaningfully convert that would be very nice for Mac & linux (and RISC OS!) users. Another option is to have an abstracted form that works from one or more known locations - the default directory is one obvious starting point - and doesn’t particularly use any  OS idea of format but can be converted easily. How about "(FileSystem defaultDir up up up dir: ‘wibble’ dir:’splot’) fileNames” instead of “(FileDirectory default directoryNamed: ‘../../../wibble/splot’) fileNames ?

An interesting option we have these days because of the common requirement for UTF-8 filenames etc is that, since we have to convert the string anyway, building a single platform format string from a collection of path components no longer seems like an insane amount of work to do for a ‘mere file name call’.

One of our problems is that people have got so used to thinking of filenames as just strings that they can append to or trim. It will be hard to get us to use anything else, no matter how much better it can be demonstrated to be.

Another problem is illustrated quite well by the horrible ways we have to guard so many methods in FileDirectory against nasty file paths being thrown around. Consider 
FileDirectory default directoryNamed: '/home’ -> UnixFileDirectory on '/home’
In order to support that we have to check the given local file name for all sorts of cruft. This may well be repeated half a dozen times in a single interaction with a file and if a hard-coded OS inappropriate string is used we can really get messed up. Proper private methods and actual APIs might help a bit here.

A different option that I suppose might seem more familiar to a lot of people would be to adopt the URI style and end up with things like ftp:blob:wiblley2 at thingummy.org//a/b/c.gif (or whatever the syntax actually is)

Whichever path we take I really hope we can build a better selection of name handling capabilities; working on the FileChooserDialog etc has really been quite annoying; oh, we can get the extension of a file name... and the local name, and the basename, but wait that includes the path… 

On the plus side, I did manage to get the basics of remote directories working within the FileChooserDialog yesterday but I’m loathe to include it since the operations seem so terribly slow. Part of it is a side-effect of our LazyList morphs compounded by slow ftp responses. Another part is the problem of a remote file name not getting parsed if we try to do FileDirectory fileNamed: ‘rowledge.org//tag-comment.gif'


tim
--
tim Rowledge; tim at rowledge.org; http://www.rowledge.org/tim
Useful random insult:- Permanently out to lunch.