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. > > 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. Thanks, Miklos
