It has always been a bit of a pet peeve of mine that blender doesn’t properly support UNC paths. These are file paths in the form of \server\share\dir\dir\file. Yes, I realize that “all” we have to do is map the share to a drive letter, but that isn’t always convenient on a large network.
Anyway, taking a quick look at the source it appears that we just error-check our way out of them (must have a colon there!) and it probably wouldn’t be a lot of work to get them working.
When I was thinking about this I got down a bit of a tangent. It seems a shame to do any work in order to just support this one new type of file descriptor. Wouldn’t it be nice to instead extend file reading to support other possibilities?
The most obvious thing is to allow for URI scheme identifiers, like “file”, “dav”, “ftp”, “http”, “https”, “nfs”, “tftp”, “urn”, “smb”, etc. For example, if a path starts with “http:” we would pass off the reading to a routine that would download the file via the http protocol. Obviously this would require that we support the concept of locally caching remote files but that wouldn’t be difficult.
This type of thing could let you have a local blend file that could use images from my remote web server and would open up cool new ways of collaborating.
I realize that I could have spent much more time thinking about this before posting, but I wanted to see if anyone else thinks this could have merit.