The current implementation, searching sequentially along a fixed list of possible translations, has a number of inefficiencies and limitations. A more efficient and more flexible approach would be to 'reverse' the process.
When a file request arrives,
1) Do a directory listing to find all files that match the base name, ie, if the request is for 'my.file', search for 'my.file$$*$$' plus 'my.file'
2) Use the discovered entries as patterns to match against, possibly allowing wildcards.
This will, of course, require definition of rules for resolving multiple matches. A reasonable approach is to select that files which match on the largest number of fields. Ie, if the list of matching files is
my.file$$IP=10.0.0.14$$
my.file$$GID=57,HOSTNAME=bee*$$
my.file
We would first examine "my.file$$GID=57,HOSTNAME=bee*$$", since it has the most fields (2). Parsing it, we arrive at two tests, first testing if GID=57. If not, we can fall through to the next match. If this matches, we then have another test "HOSTNAME=bee*". This time we have a wildcard so we need to do pattern matching.
If the file matched and is accessable, (readable) return it, otherwise, try the next filename in the list.
