First off, I again have to caution that this thread is conflating "open" with filesystem interaction. While open is one of many ways of interacting with a filesystem, it isn't even remotely sufficient (nor my immediate focus). One can ask for and modify filesystem metadata, security information, and so on as well as that for individual objects within the filesystem (which in the POSIX model is mostly files and directories). In a traditional POSIX/Unix model, programs (other than key OS utilities) don't usually do much with the structure of the filesystem. That's meant as an interactive task for an admin. However, in building a cloud-storage aware VFS-layer, managing the filesystem in terms of layout, allocation, security (access methods, authorization and authentication), payment models, and many other features are expected to be embodied in the access model. Just as an example, choosing and laying out what Amazon calls "buckets" is the equivalent of partitioning. That does need an interface.
Now, we can just translate the Python bindings for Google Storage (and I believe there are already Perl 5 bindings for Amazon S3), but my inclination is to build a generic VFS that can handle POSIX-like filesystems as well as everything else from Windows/Mac specific features to full-blown cloud storage to more user-oriented storage options (Dropbox comes to mind). Every addressable storage model which could be treated as a filesystem should have a place in the Perl 6 VFS. Now, as to the question of overloading "open"... I'm not sure. I mean, it's pretty easy to say: URI.new($path).open(:ro) or open(URI.new($path), :ro) When what you want is a VFS object, and I kind of like the idea of the standard open on a string having POSIX semantics. Now, to your question, C.J. On Fri, Jun 18, 2010 at 3:03 PM, C.J. Adams-Collier <c...@colliertech.org> wrote: > Define "opening a file" for me. Is it something that's associated with a > filehandle, by definition? Do TCP sockets count? Opening a file isn't a well defined operation. You have to be more specific. In your question you're conflating the evaluation of a filesystem namespace token (which is one of many possible modes of filesystem interaction), returning a filehandle object that represents access to the named object with evaluation of a socket namespace token and returning a similar filehandle object that represents that object. There are, of course crossovers (filesystem pipes) and other operations that yield filehandle objects (various IPC operations that aren't exactly sockets, for example). Now, if you want to unify some of that territory, you can build a VFS layer. Today, that's often done via URIs, just because they're handy for Identifying Universal Resources, but what happens when you call open (or equivalent) on such a token is still an open question, and I didn't seek to answer it in this thread. Franky, I don't think that it's something that SHOULD be answered prior to building the VFS layer itself, because that layer might dictate some design decisions, but my high level impulse is to say that open on a VFS token (be it a URI or some othe complex data) will yield a VFS-back-end specific "handle". Such a handle would likely "do" IO::Handle and friends as well as something VFS-specific. -- Aaron Sherman Email or GTalk: a...@ajs.com http://www.ajs.com/~ajs
