But I was wondering - why not give every resource in your software application an IPV6 address? Every function, every file - anything in your system that might need to be located/addressed.
Happy to be shot down but one of the most common challenges in software development at every level is trying to find things. It occurred to me that IPV6 would allow pretty much everything to have a number, even down to the level of individual objects/methods/data structures.
Is there any merit to the idea? Or is it a bad idea all the way down because ....... x?
I suppose I could imagine a system like that. Files could be IPv6 addressable entities that can communicate using some file access protocol, and functions could be entities that receive their arguments as the IPv6 packets I send them and that could respond with whatever their return value is.
This is too different from current OS conventions, though. Also, I'm not sure what the benefits would be. If I have an IPv6 address, how would I know that it's a local file and not a host on the other side of the planet? Wouldn't that be a problem? If a directory tells me it has a file with a certain IPv6 address, and I try to open it, is there the possibility it would send a file open request to a host elsewhere on the planet? Would I be waiting for a response to open the file until the host replies that it doesn't serve that protocol?
Simply addressing things via IPv6 instead of UIDs is easy. The question I'd have is "then what?" Since presumably doing this has a specific purpose, and it isn't self evidence what that purpose is (e.g. Are you using IP coms for local IPC? Are you using it for diagnostics? Is this meant to solve interoperability? Etc).
It is neither a "bad" nor "good" idea. It is a neutral idea that could be used either way.