> Christian Mayrhuber > > What about using // as some URI entry point? > An URI looks like: > PROTOCOL://PROTOCOL_SPECIFIC_NAMESPACE_IMPLEMENTATION > I considered that in that //: is implicitly file://, but didn't make it explicit in the proposal. Perhaps //: could be a legal alias for //file://.
> ... > > If someone wants to expose filesystem metadata > something like //metas:// instead of //: could do it. > > //metas://a-directory/SomeName regular dir entry > //metas://a-directory//SomeName named stream > //metas://a-directory///SomeName == //metas://a- > directory/SomeName > But this means that metas:// becomes an alias for file:// depending upon what you want to access. If we want to explicitly require a URI for files, which may be the way to go, then there should be one protocol for file access, file://. The semantics for that would be such that // on the end of a file or directory means "access the named stream if the a) VFS supports this and b) the device where the named object resides supports named streams." Programs that want to access named streams would use //file://a-directory//SomeName to access the streams as well as normal objects. Apps that exclusively use the URI-style path would need to be more precise that is required today. Today it works to concatenate "/home/" and "/"myfile" and references the correct file. Under URI semantics, this would fail or not behave as expected. David
