ServerDirectory example login is dead

Previous Topic Next Topic
 
classic Classic list List threaded Threaded
4 messages Options
Reply | Threaded
Open this post in threaded view
|

ServerDirectory example login is dead

timrowledge
If one tries to add a remote directory to a FileList the example server  details lists the no longer extant st.cs.uiuc.edu, which is a little disappointing.

Do we have a good replacement? Preferably a good place on our own server(s)? I did actually try files.squeak.org but that
a) failed
b) exposed me to the great joy of a loop of unhandled error handling handling errors in erroneous handling.

I *can* get to my own server, so the basics still function - but I’m not providing access to that for the world in general.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Hypnotized as a child and couldn't be woken.



Reply | Threaded
Open this post in threaded view
|

Re: ServerDirectory example login is dead

timrowledge
… which leads me to note that ServerDirectory/RemoteFileStream seem to need some love, and it would be nice to integrate them better wrt file name stuff.

See ServerDirectory class>>#defaultStemUrl, for example - I’m fairly sure disney wouldn’t want us trying to save Books on ‘jumbo’ any more.

Consider that whilst FileList tries to handle remote directories, it fails horribly if you try to look at, say, a gif file on a remote server because the code asks for the full name of the file (rowledge.org//tag-comment.gif for example) and passes that to Form fromFileNamed: Since our filename handling stinks, it doesn’t work out that it needs to make a remote file stream etc.   It really is way past time we had a decent file name handling system that can sensibly deal with stuff like that, and the need to (often) convert file name related strings to/from UTF-8 when talking to a VM, and so on and so forth.

tim
--
tim Rowledge; [hidden email]; http://www.rowledge.org/tim
Strange OpCodes: SLTMDL: Shift Left, Test Mask and Dim the Lights



Reply | Threaded
Open this post in threaded view
|

Re: ServerDirectory example login is dead

Jakob Reschke-2
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.

Am 26.12.2017 22:15 schrieb "tim Rowledge" <[hidden email]>:
… which leads me to note that ServerDirectory/RemoteFileStream seem to need some love, and it would be nice to integrate them better wrt file name stuff.

See ServerDirectory class>>#defaultStemUrl, for example - I’m fairly sure disney wouldn’t want us trying to save Books on ‘jumbo’ any more.

Consider that whilst FileList tries to handle remote directories, it fails horribly if you try to look at, say, a gif file on a remote server because the code asks for the full name of the file (rowledge.org//tag-comment.gif for example) and passes that to Form fromFileNamed: Since our filename handling stinks, it doesn’t work out that it needs to make a remote file stream etc.   It really is way past time we had a decent file name handling system that can sensibly deal with stuff like that, and the need to (often) convert file name related strings to/from UTF-8 when talking to a VM, and so on and so forth.
Strange OpCodes: SLTMDL: Shift Left, Test Mask and Dim the Lights






Reply | Threaded
Open this post in threaded view
|

Re: ServerDirectory example login is dead

timrowledge

> On 27-12-2017, at 3:36 AM, Jakob Reschke <[hidden email]> 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:[hidden email]//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; [hidden email]; http://www.rowledge.org/tim
Useful random insult:- Permanently out to lunch.