On Dienstag, 25. August 2020 17:32:15 CEST Miklos Szeredi wrote:
> On Tue, Aug 25, 2020 at 5:12 PM Christian Schoenebeck
>
> <qemu_oss@xxxxxxxxxxxxx> wrote:
> > I can give you another argument which might be more convincing to you: say
> > you maintain a middleware lib that takes a path as argument somewhere,
> > and that lib now gets path="/foo//bar". How could that lib judge whether
> > it should a) eliminate the double slash, or rather b) it was really meant
> > to be fork "bar" of file "foo" and hence shall pass the string as-is to
> > underlying
> > framework(s)? Simply: It can't, as it requires knowledge from either upper
> > or lower end that the lib in the middle might not have.
>
> Nobody needs to care, only the level that actually wants to handle the
> alternative namespace. And then that level absolutely *must* call
> into a level that it knows does handle the alternative namespace.
>
> Yeah, it's not going to suddenly start to work by putting "foo//bar"
> into an open file dialogue or whatever. That's not the point, adding
> that new interface is to enable *new* functionality not to change
> existing functionality. That's the point that people don't seem to
> get.
I think you are underestimating the negative impact an n-times-slash delimiter
would introduce. Middleware functionalities rely on unumbiguous path name
resolution for being able to transform pathes without asking another level how
it shall a) parse and b) interpret individual components of a path.
It would not be as simple as saying, they are now broken, let's fix them.
Because path transformations happen so often on all levels on any system, that
if you'd introduce a dependency for that (i.e. a simple path transformation
would need to ask e.g. a storage backend for help), then it would slow down
overall performance tremendously, especially as such requests are typically
non-deterministic.
E.g. it is very common for a middleware function to transform a path into a
list, and "/a/b//c/d" would now be ambiguous:
"/a/b//c/d" -> [ "a", "b", "c", "d" ]
or
"/a/b//c/d" -> [ "a", "b", [ "c", "d" ] ]
You can't simply pass either one option to the next level, because it would
break behaviour:
foreach (dir_entry in [ "a", "b", "c", "d" ]) {
dirAction(dir_entry)
}
is different than:
foreach (dir_entry in [ "a", "b" ]) {
dirAction(dir_entry)
foreach (fork_entry in [ "c", "d" ]) {
forkAction(fork_entry)
}
}
Hence that simple path transformation would need to ask for help to resolve
the ambiguity, which might take anything between few microseconds up to
several seconds, then multiply that duration with the common amount of
individual path transformations involved in just a very simple task.
---
What I could imagine as delimiter instead; slash-caret:
/var/foo.pdf/^/forkname
I also like Microsoft's colon pick, as it would make shell interactions more
slick:
/var/foo.pdf:forkname
However I am aware that the colon would probably be too drastic, as colons are
often used to separate individual pathes in a list for instance.
> > > The most important thing, I think, is to not fragment the interface
> > > further. So O_ALT should allow not just one application (like ADS)
> > > but should have a top level directory for selecting between the
> > > various data sources.
> >
> > Well, that's what name spaces are for IMO. So you would probably reserve
> > some prefixes for system purposes, like it is already done for Linux
> > xattrs. Or do you see any advantage for adding a dedicated directory
> > layer in between instead?
>
> You mean some reserved prefixes for ADS? Bleh.
>
> No, xattr is not the model we should be following.
Maybe. I am actually unresolved about that. As that fs meta info PR recently
showed, there might be other future use cases for this interface that one
probably cannot foresee today; and a dedicated toplevel directory to choose
between them would also make the kernel internal bindings more clean. So you
might have for instance:
/var/foo.pdf/^/alt/forkname # for common ADS (incl. macOS data forks)
/var/foo.pdf/^/res/forkname # for mapping macOS resource forks
/var/foo.pdf/^/meta/forkname # for accessing fs implementation info
Best regards,
Christian Schoenebeck
