[ANN] Filesystem 1.0
Locked
12
12
 
|
+1 for URIs, portable access is good.
Regards, Gary ----- Original Message ----- From: "John M McIntosh" <[hidden email]> To: "The general-purpose Squeak developers list" <[hidden email]> Sent: Monday, November 23, 2009 4:42 PM Subject: Re: [squeak-dev] Re: [ANN] Filesystem 1.0 On 2009-11-23, at 7:26 AM, Colin Putney wrote: > One thing that is interesting is that they use URIs, with made-up schema > that map to their filesystem providers. So a Reference to a file in a > MemoryFilesystem would have a url like > > ram:/path/to/my/file. > > And files inside zip archives look like: > > file:///path/to/archive.zip!/path/to/file > > Java folks expect to us URIs everywhere. I wonder how well that would work > in Smalltalk. I'll play broken record, and say yes we did this in Sophie. All resource references to file like things was via URI. We also did the "made-up schema" so that we could refer to cached memory files versus http: or file: -- =========================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== |
|
|
In reply to this post by Colin Putney
Sophie user's dragged media from disk file systems, the internet (yes we would copy or leave as a URI), and internally there was cached memory based URIs.
Sophisticated Sophie book could have hundreds if not thousands of then located in memory, the file system, or on the internet. Every reference was a URI, either absolute or based on the book's URI, then we could base the book in memory, on disk, or on the internet. We never passed or used a raw file path anywhere in the system. The URI class had the responsibility to take a UTF8 platform raw file path and convert to a proper usable delimited URI. For internet based URIs, we did find some of the browsers had different thoughts on how to interpreter a delimited UTF8 URI with accented characters, but we viewed that issue as bugs in their implementation. At the point where we needed a read/'write stream we used the URI to make the stream, file:, http:, memory: On the macintosh and on windows quicktime, they were quite happy to consume URI strings when asked to open media files (file: http:) On 2009-11-23, at 8:51 AM, Colin Putney wrote: > > On 23-Nov-09, at 8:42 AM, John M McIntosh wrote: > >>> Java folks expect to us URIs everywhere. I wonder how well that would work in Smalltalk. >> >> I'll play broken record, and say yes we did this in Sophie. All resource references to file like things was via URI. >> We also did the "made-up schema" so that we could refer to cached memory files versus http: or file: > > Ok, but that doesn't answer my question. How well did it work? What was good about it? What was bad about it? Was it a natural fit in Smalltalk, or did it take some shoehorning to make it work? > > Colin > -- =========================================================================== John M. McIntosh <[hidden email]> Twitter: squeaker68882 Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com =========================================================================== |
|
|
In reply to this post by Eliot Miranda-2
On Saturday 21 November 2009 10:35:31 am Eliot Miranda wrote:
> Even though the Windows drive letters do map to > different file systems they are still a single namespace. In Windows, drive letters are indexes into a volume table - more like partition names in Unix (/dev/sda1, /dev/sdb2 etc) or in Grub ( (hd0,1), (hd1,2), ...). They are not treated as part of a namespace. Unix has one and only one index (root) named "" (zero length symbol). Subbu |
|
|
In reply to this post by Colin Putney
> Hey, thanks for this link. It *is* quite interesting; they're definitely
Keeping with the theme of URI's, would Resource be a better name?> trying accomplish the same sort of thing that I am. I had hoped to steal > some of their terminology, but... Reference maybe sort of meaningless > but it's better than FileObject. :-) > > One thing that is interesting is that they use URIs, with made-up schema > that map to their filesystem providers. So a Reference to a file in a > MemoryFilesystem would have a url like > > ram:/path/to/my/file. > > And files inside zip archives look like: > > file:///path/to/archive.zip!/path/to/file > > Java folks expect to us URIs everywhere. I wonder how well that would > work in Smalltalk. > > Colin > No virus found in this outgoing message. Checked by AVG - www.avg.com Version: 8.5.425 / Virus Database: 270.14.77/2520 - Release Date: 11/22/09 19:40:00 |
|
|
In reply to this post by Colin Putney
Hi Colin -
Colin Putney wrote: > On 21-Nov-09, at 3:22 PM, Andreas Raab wrote: >> I think you should change the terminology slightly. Having the >> implementation specific thing called "path" and the user visible >> entity called "reference" is confusing - when I was looking at the >> code I saw "oh, there's a path, yeah, that's what I'm looking for". >> The term "reference" didn't ring a bell with me. In other words, I >> would have users deal with FSPath objects and rename the current >> FSPath to something obviously obscure, for example >> "FSPathSequenceImpl" or something to make obviously clear that from >> the user perspective you're going to deal with the FSPath only. > > Yes. Terminology is both important and difficult. I'm not very happy > with the term "reference" either, but I can't think of anything better. > The thing I called "path" really is a path, where as "references" are > something more than a path. That said, it may be wiser to bow to the > intuition of users, even though their intuition is wrong. :-) Heh. Not saying you have to but then perhaps just making the short (and to users very meaningful!) name of "FSPath" be a little less short and meaningful might be helpful. Just ask yourself "which class would *I* look at first if I read all these names and wanted to figure out what to use?". To me, FSPath came clearly before FSReference when we're talking about file system stuff. > I'm not sure I understand the problem with multiple filesystems on > Windows. Sure, you stumbled over some exposed girders trying to > enumerate the available drives, but that doesn't mean the building isn't > structurally sound. Oh, don't get me wrong here, I'm not saying it's structurally unsound. What I'm saying is that for my practical use the ability to manipulate the drive/share in the same namespace that the directory lives in is more useful than modeling the underlying DOS semantics precisely. Speaking from the perspective of the apps that I've actually written, precisely none of them cared for those dos current drive and cwd semantics, simply because no Windows user interacts with them outside the shell (which on Windows practically nobody uses anyway). Even though you're able to type 'em into the explorer bar no user does that in practice. And even then, the places where you'd have to deal with those concepts are in file open / save dialogs where in any real app you use the native dialogs anyway (which may or may not support that but it's out of your control). In short, what I'm saying is that I don't know of situation short of writing a shell replacement that would require us to support that DOS semantics precisely. However, pretty much all of the cross-platform stuff I write with regards to file handling depends on being able to manipulate drive and share names as part of the filesystem namespace on Windows. I'm simply asking for making it possible to manipulate those names in a consistent way. How that is achieved is irrelevant from my perspective - if you prefer to do this by a "virtual mount" or something else isn't all that important to me. Cheers, - Andreas |
|
|
In reply to this post by Gary Chambers-4
Gary Chambers wrote:
> +1 for URIs, portable access is good. Yes, portable access is good, but one of the things that I'm wary about is that you may end up with code which claims to support URIs when really it only supports files. The difference being that a file is a local resource and as a consequence the type and frequency of failures, latency and bandwidth are vastly different from that of a remote resource. I've never used URIs throughout so take the following with a grain of salt but generally speaking I'm not a big fan of mixing access to resources with such different failure modes and latencies. I've found that a distinction between local resources (highly reliable, low latency, high bandwidth) and remote resources (unreliable, high latency, low bandwidth) is very helpful when dealing with resources in distributed systems. Cheers, - Andreas > ----- Original Message ----- From: "John M McIntosh" > <[hidden email]> > To: "The general-purpose Squeak developers list" > <[hidden email]> > Sent: Monday, November 23, 2009 4:42 PM > Subject: Re: [squeak-dev] Re: [ANN] Filesystem 1.0 > > > > On 2009-11-23, at 7:26 AM, Colin Putney wrote: > >> One thing that is interesting is that they use URIs, with made-up >> schema that map to their filesystem providers. So a Reference to a >> file in a MemoryFilesystem would have a url like >> >> ram:/path/to/my/file. >> >> And files inside zip archives look like: >> >> file:///path/to/archive.zip!/path/to/file >> >> Java folks expect to us URIs everywhere. I wonder how well that would >> work in Smalltalk. > > I'll play broken record, and say yes we did this in Sophie. All resource > references to file like things was via URI. > We also did the "made-up schema" so that we could refer to cached memory > files versus http: or file: > > > -- > =========================================================================== > John M. McIntosh <[hidden email]> Twitter: > squeaker68882 > Corporate Smalltalk Consulting Ltd. http://www.smalltalkconsulting.com > =========================================================================== > > > > > > > |
Re: Re: [ANN] Filesystem 1.0
|
|
In reply to this post by Colin Putney
2009/11/21 Colin Putney <[hidden email]>
I really need to rewrite the tutorial to de-emphasize paths. You should use FSReference for everything. Once I get Eliot's suggestion implemented, the above will be: Hi I don't like global objects referencess in code. I cant mock global object in tests. I like VW dsl for that. For FileSystem it's can be: 'd://squeak/3.10' asFileReference. And delimiter "/" is just squeak delimiter (not OS filenames delimiter). #asFileReference can be implemented like that: String>>asFileReference FileSystem default parseFileReference: this. I think this approach hides windows disks logic. And for different FileSystem (not defafult) it's can be: 'squeak' / '3.10' asFileReferenceOn: aFileSystem |
|
|
On 23-Nov-09, at 10:41 PM, Denis Kudriashov wrote: > 2009/11/21 Colin Putney <[hidden email]> > I really need to rewrite the tutorial to de-emphasize paths. You > should use FSReference for everything. Once I get Eliot's suggestion > implemented, the above will be: > > ref := FSReference D / 'Squeak' / '3.10'. > > Hi > > I don't like global objects referencess in code. I cant mock global > object in tests. > I like VW dsl for that. For FileSystem it's can be: > > 'd://squeak/3.10' asFileReference. I'm not sure I follow. The only global here is the class FSReference. #D is an instance creation method. I don't see how the message you suggest is any more flexible. You can't mock out the implementation of asFileReference any more easily than that of #D, right? > And delimiter "/" is just squeak delimiter (not OS filenames > delimiter). Yes, exactly. It's meant to be a cross-platform, reasonably clear way of specifying a path. It's not meant to match the platform path syntax exactly. Does that make any sense to you? Colin |
Re: Re: [ANN] Filesystem 1.0
|
|
2009/11/24 Colin Putney <[hidden email]>
No. But maybe it's not really problem. For method writeMessageTo: filename FSReference / filename writeStreamDo: [:s | ... ] I can't mock writing data to real file. But I can rewrite this method with "filename" as FSReference: writeMessageTo: filename filename writeStreamDo: [:s | ... ] And now I can mock this behavior by pass mockobject as filename instead of real FSReference. And I think syntax based on strings more simple and elegant: 'smalltalk' \ 'squeak' \ '3.10' writeStreamDo: [: f | ] 'smalltalk\squeak' \ '3.10' writeStreamDo: [: f | ] 'smalltalk\squeak' asFileReference And last expression will hide work with disks on windows (when we wrote 'c:/smalltalk' asFileReference or 'c:' \ 'smalltalk' ) I use message #\ because #/ already used in String protocol |
Re: Re: [ANN] Filesystem 1.0
|
|
In reply to this post by Andreas.Raab
On Tuesday 24 November 2009 10:39:24 am Andreas Raab wrote:
> Yes, portable access is good, but one of the things that I'm wary about > is that you may end up with code which claims to support URIs when > really it only supports files. The difference being that a file is a > local resource and as a consequence the type and frequency of failures, > latency and bandwidth are vastly different from that of a remote resource. "file" has two meanings as used in this discussion - a stream protocol or a locator for a physical file. In Squeak, file i/o is more of a protocol between the VM and the image than a store (i.e. does not care where or how it is stored on the host). FilePlugin is a good place to hide pathname ugliness. URI is just one option for a such a protocol. Plan 9 uses a simpler design that would suit traditional file stores (see http://plan9.bell- labs.com/sys/doc/names.html). Colin's design is clean and functional for his purposes. It has some gaps that need to be filled before it can be adopted as another protocol in Squeak. The paper above covers some of the protocol gaps (rename, links, hidden/temporary attributes, copy on write, mounts, devices like serial ports). Subbu |
«
Return to Squeak - Dev
|
1 view|%1 views
| Free forum by Nabble | Edit this page |