stephen at xemacs.org wrote: > Talin writes: > > (one additional postscript - One thing I would be interested in is an > > approach that unifies file paths and URLs so that there is a consistent > > locator scheme for any resource, whether they be in a filesystem, on a > > web server, or stored in a zip file.) > > +1 > > But doesn't file:/// do that for files, and couldn't we do something > like zipfile:///nantoka.zip#foo/bar/baz.txt? Of course, we'd want to > do ziphttp://your.server.net/kantoka.zip#foo/bar/baz.txt, too. That > way leads to madness.... file:/// does indeed to it, but only the network module understands strings in that format. Ideally, you should be able to pass "file:///..." to a regular "open" function. I wouldn't expect it to be able to understand "http://". But the "file:" protocol should always be supported. In other words, I'm not proposing that the built-in file i/o package suddenly grow an understanding of network schema types. All I am proposing is a unified name space. - Talin
RetroSearch is an open source project built by @garambo | Open a GitHub Issue
Search and Browse the WWW like it's 1997 | Search results from DuckDuckGo
HTML:
3.2
| Encoding:
UTF-8
| Version:
0.7.4